rfc9628xml2.original.xml   rfc9628.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2119.xml">
<!ENTITY rfc3264 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3264.xml">
<!ENTITY rfc3550 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3550.xml">
<!ENTITY rfc3551 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3551.xml">
<!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">
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<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 --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-payload-vp9- 16" number="9628" ipr="trust200902" obsoletes="" updates="" submissionType="IETF " category="std" consensus="true" xml:lang="en" symRefs="true" sortRefs="true" t ocInclude="true" version="3">
<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</title> Video</title>
<seriesInfo name="RFC" value="9628"/>
<author fullname="Justin Uberti" initials="J." surname="Uberti"> <author fullname="Justin Uberti" initials="J." surname="Uberti">
<organization abbrev="Google">Google, Inc.</organization> <organization abbrev="Google">Google, Inc.</organization>
<address> <address>
<postal> <postal>
<street>747 6th Street South</street> <street>747 6th Street South</street>
<city>Kirkland</city> <city>Kirkland</city>
<region>WA</region> <region>WA</region>
<code>98033</code> <code>98033</code>
<country>United States of America</country>
<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">Google, Inc.</organization>
<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>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">Google, Inc.</organization>
<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">Google, Inc.</organization> <organization abbrev="Google">Google, Inc.</organization>
<address> <address>
<postal> <postal>
<street>1585 Charleston Road</street> <street>1585 Charleston Road</street>
<city>Mountain View</city> <city>Mountain View</city>
<region>CA</region> <region>CA</region>
<code>94043</code> <code>94043</code>
<country>United States of America</country>
<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">8x8, Inc. / Jitsi</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 year="2024" month="August" />
<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> <abstract>
<t>This specification describes an RTP payload format for the VP9 video co dec. <t>This specification describes an RTP payload format for the VP9 video co dec.
The payload format has wide applicability, as it supports applications The payload format has wide applicability as it supports applications
from low bit-rate peer-to-peer usage, to high bit-rate video from low bitrate peer-to-peer usage to high bitrate video
conferences. It includes provisions for temporal and spatial scalability. </t> conferences. It includes provisions for temporal and spatial scalability. </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<t>This specification describes an <xref target="RFC3550">RTP</xref> paylo <name>Introduction</name>
ad specification applicable to the
transmission of video streams encoded using the VP9 video codec <xref
target="VP9-BITSTREAM"/>. The format described in this document can be use
d
both in peer-to-peer and video conferencing applications.</t>
<t>The VP9 video codec was developed by Google, and is the <t>This document describes an <xref target="RFC3550"
successor to its earlier <xref target="RFC6386">VP8</xref> format="default">RTP</xref> payload specification applicable to the
codec. Above the compression improvements and other general transmission of video streams encoded using the VP9 video codec <xref
enhancements above VP8, VP9 is also designed in a way that target="VP9-BITSTREAM" format="default"/>. The format described in this
allows spatially-scalable video encoding.</t> document can be used both in peer-to-peer and video conferencing
applications.</t>
<t>The VP9 video codec was developed by Google and is the successor to
its earlier <xref target="RFC6386" format="default">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" <!--[rfced] Please note that we have updated the title of Section 2 to
title="Conventions, Definitions and Acronyms"> more accurately describe its contents. Please let us know any
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", objections.-->
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.</t>
</section>
<section anchor="mediaFormatDescription" title="Media Format Description"> <section anchor="conventions" numbered="true" toc="default">
<name>Conventions</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
</section>
<section anchor="mediaFormatDescription" numbered="true" toc="default">
<name>Media Format Description</name>
<t>The VP9 codec can maintain up to eight reference frames, of <t>The VP9 codec can maintain up to eight reference 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>VP9 also allows a frame to use another frame of a different <t>VP9 also allows a frame to use another frame 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>These features together enable an encoder to <t>These features together enable an encoder to
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>Temporal layers define different frame rates of video; <t>Temporal layers define different frame rates 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>This payload format specification defines how such <t>This payload format specification defines how such
temporal and spatial scalability layers can be described and temporal and spatial scalability layers can be described and
communicated.</t> communicated.</t>
<t>Temporal and spatial scalability layers are associated with
<t>Temporal and spatial scalability layers are 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 0 and is sometimes referred to as the "base" temporal or
spatial layer.</t> spatial layer.</t>
<t>Layers are designed, and <bcp14>MUST</bcp14> be encoded, such that if
<t>Layers are designed, and MUST 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>For terminology, this document uses the term "frame" to refer <!--[rfced] Might replacing the slash in the following with "and",
to a single encoded VP9 frame for a particular resolution/quality, and "or", or "and/or" be helpful to the reader?
Original:
...for a particular resolution/quality,...
-->
<t>For terminology, this document uses the term "frame" to refer to a
single encoded VP9 frame for a particular resolution/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>Within a picture, a frame with spatial layer ID equal to SID, <t>Within a picture, a frame with
where SID > 0, can depend on a frame of the same picture with a lower spat spatial-layer ID equal to SID, where SID &gt; 0, can depend on a frame
ial layer ID. This of the same picture with a lower spatial-layer ID. This "inter-layer"
"inter-layer" dependency can result in additional coding gain dependency can result in additional coding gain compared to the case
compared to the case where only where only traditional "inter-picture" dependency is used, where a frame
traditional "inter-picture" dependency is used, where a frame depends on p depends on a previously coded frame in time. For simplicity, this
reviously payload format assumes that, within a picture and if inter-layer
coded frame in time. For simplicity, this payload format assumes that, dependency is used, a spatial-layer SID frame can depend only on the
within a picture and if inter-layer dependency is used, a spatial layer SI immediately previous spatial-layer SID-1 frame, when S &gt; 0.
D frame Additionally, if inter-picture dependency is used, a spatial-layer SID
can depend only on the immediately previous spatial layer SID-1 frame, whe frame is assumed to only depend on a previously coded spatial-layer SID
n S > 0. Additionally, if frame.</t>
inter-picture dependency is used, a spatial layer SID frame is assumed to
only
depend on a previously coded spatial layer SID frame.</t>
<t>Given above simplifications for inter-layer and inter-picture <!-- [rfced] FYI: We've updated the following sentence by adding "a"
dependencies, a flag (the D bit described below) is used to indicate wheth before "previously coded frame in time". Please let us know if
er a this changes the intended meaning.
spatial layer SID frame depends on the spatial layer SID-1 frame. Given t
he D bit, a receiver
only needs to additionally know the inter-picture dependency structure for
a given
spatial layer frame in order to determine its decodability. Two modes
of describing the inter-picture dependency structure are possible:
"flexible mode" and "non-flexible mode". An encoder can only switch
between the two on the first packet of a key frame with temporal
layer ID equal to 0.</t>
<t>In flexible mode, each packet can contain up to 3 reference Original:
indices, which identify all frames referenced by the frame This "inter-layer" dependency can result in additional coding gain
transmitted in the current packet for inter-picture prediction. compared to the case where only traditional "inter-picture" dependency is
This (along with the D bit) enables a receiver to identify if a frame used, where a frame depends on previously coded frame in time.
is decodable or not and helps it understand the temporal layer
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
>
Updated:
This "inter-layer" dependency can result in additional coding gain
compared to the case where only traditional "inter-picture" dependency is
used, where a frame depends on a previously coded frame in time.
-->
<t>Given the above simplifications for inter-layer and inter-picture
dependencies, a flag (the D bit described below) is used to indicate
whether a spatial-layer SID frame depends on the spatial-layer SID-1
frame. Given the D bit, a receiver only needs to additionally know the
inter-picture dependency structure for a given spatial-layer frame in
order to determine its decodability. Two modes of describing the
inter-picture dependency structure are possible: "flexible mode" and
"non-flexible mode". An encoder can only switch between the two on the
first packet of a keyframe with a temporal-layer ID equal to 0.</t>
<t>In flexible mode, each packet can contain up to three reference indices
,
which identify all frames referenced by the frame transmitted in the
current packet for inter-picture prediction. This (along with the D
bit) enables a receiver to identify if a frame is decodable or not and
helps it understand the temporal-layer 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; <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). the set of pictures that recur in this pattern is known as a "Picture Grou p" (or "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>
<!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside)
.
-->
<t>(Note: A "Picture Group", as used in this document, <t>Note: A "Picture Group" or "PG", as used 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 traditionally 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>
<t>The SS data can also be used to specify the resolution of each <t>The SS data can also be used to specify the resolution of each
spatial layer present in the VP9 stream for both flexible and non-flexible modes.</t> spatial layer present in the VP9 stream for both flexible and non-flexible modes.</t>
</section> </section>
<section anchor="payloadFormat" numbered="true" toc="default">
<name>Payload Format</name>
<!--[rfced] Should "the specifications" in this text be clarified for
the reader?
Original:
All integer fields in the specifications are encoded as unsigned
integers in network octet order.
-->
<section anchor="payloadFormat" title="Payload Format">
<t>This section describes how the encoded VP9 bitstream is encapsulated <t>This section describes how the encoded VP9 bitstream is encapsulated
in RTP. To handle network losses usage of RTP/AVPF <xref in RTP. To handle network losses, usage of RTP/AVPF <xref target="RFC4585"
target="RFC4585"/> is RECOMMENDED. All integer fields in the format="default"/> is <bcp14>RECOMMENDED</bcp14>. All integer fields in the
specifications are encoded as unsigned integers in network octet specifications are encoded as unsigned integers in network octet
order.</t> order.</t>
<section anchor="RTPHeaderUsage" numbered="true" toc="default">
<name>RTP Header Usage</name>
<t keepWithNext="true">The general RTP payload format for VP9 is depicte
d
below.</t>
<section anchor="RTPHeaderUsage" title="RTP Header Usage"> <figure anchor="figureRTPHeader" title="General RTP Payload Format for
<figure anchor="figureRTPHeader"> VP">
<preamble>The general RTP payload format for VP9 is depicted <artwork type="" align="left" alt=""><![CDATA[
below.</preamble>
<artwork><![CDATA[
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 291
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | | : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
+ | + |
: 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">See <xref target="VP9payloadDescriptor" forma
t="default"/> for more information on the VP9 payload descriptor;
the VP9 payload is described in <xref target="VP9-BITSTREAM"
format="default"/>. <bcp14>OPTIONAL</bcp14> RTP padding <bcp14>MUST
NOT</bcp14> be included unless the P bit is set.</t>
<t><list style="hanging"> <!--[rfced] [*AD] In the following, we believe restructuring the text
<t hangText="Marker bit (M):">MUST be set to 1 for the final packet may clarify the applicability of the BCP 14 keywords (are both
of the highest spatial layer frame (the final packet of the picture) parts of the sentence MUSTs?). Please review.
,
and 0 otherwise. Unless spatial scalability is in use for this pict
ure,
this will have the same value as the E bit described below. Note th
is bit
MUST be set to 1 for the target spatial layer frame
if a stream is being rewritten to remove higher spatial layers.</t>
<t hangText="Payload Type (PT):">In line with the policy Instance 1:
in Section 3 of <xref target='RFC3551'/>, applications
using the VP9 RTP payload
profile MUST assign a dynamic payload type number to be
used in each RTP session and provide a mechanism to
indicate the mapping. See <xref target="SDPParameters"
/> for the mechanism
to be used with the <xref target='RFC8866'>Session
Description Protocol (SDP)</xref>.</t>
<t hangText="Timestamp:">The <xref target="RFC3550">RTP timestamp</x Original:
ref> indicates the time when Marker bit (M): MUST be set to 1 for the final packet of the highest
the input frame was sampled, at a clock rate of 90 kHz. If the spatial layer frame (the final packet of the picture), and 0
input picture is encoded with multiple layer frames, all of the otherwise.
frames of the picture MUST have the same timestamp.</t>
<t>If a frame has the VP9 show_frame field set to 0 (i.e. Perhap A:
, it is meant only to Marker bit (M): This bit MUST be set to 1 for the final packet of
populate a reference buffer, without being output) its the highest spatial-layer frame (the final packet of the picture);
timestamp MAY alternatively be set otherwise, it MUST be 0.
to be the same as the subsequent frame with show_frame
equal to 1. (This will
be convenient for playing out pre-encoded content packa
ged with VP9 "superframes", which
typically bundle show_frame==0 frames with a subsequent
show_frame==1 frame.) Every
frame with show_frame==1, however, MUST have a unique t
imestamp modulo the 2^32 wrap of
the field.</t>
</list></t> Perhaps B:
<t>The remaining RTP Fixed Header Fields (V, P, X, CC, Marker bit (M): This bit MUST be set to 1 for the final packet of
sequence number, SSRC and CSRC identifiers) are used as the highest spatial-layer frame (the final packet of the picture);
specified in Section 5.1 of <xref otherwise, it is 0.
target="RFC3550"/>.</t>
Instance 2:
Original:
MUST be set to 1 for the final RTP packet of a
VP9 frame, and 0 otherwise
Perhaps A:
This bit MUST be set to 1 for the final RTP packet of a VP9 frame;
otherwise, it MUST be 0.
Perhaps B:
This bit MUST be set to 1 for the final RTP packet of a VP9 frame;
otherwise, it is 0.
-->
<dl newline="false" spacing="normal">
<dt>Marker bit (M):</dt>
<dd>This bit <bcp14>MUST</bcp14> be set to 1 for the final packet
of the highest spatial-layer frame (the final packet of the picture)
,
and 0 otherwise. Unless spatial scalability is in use for this pict
ure,
this bit will have the same value as the E bit described in <xref ta
rget="VP9payloadDescriptor"/>. Note this bit
<bcp14>MUST</bcp14> be set to 1 for the target spatial-layer frame
if a stream is being rewritten to remove higher spatial layers.</dd>
<dt>Payload Type (PT):</dt>
<dd>In line with the policy in <xref target="RFC3551"
sectionFormat="of" section="3" format="default"/>, applications using
the VP9 RTP payload profile <bcp14>MUST</bcp14> assign a dynamic
payload type number to be used in each RTP session and provide a
mechanism to indicate the mapping. See <xref target="SDPParameters"
format="default"/> for the mechanism to be used with the <xref
target="RFC8866" format="default">Session Description Protocol
(SDP)</xref>.</dd>
<dt>Timestamp:</dt>
<dd>The <xref target="RFC3550" format="default">RTP timestamp</xref> i
ndicates the time when
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
frames of the picture <bcp14>MUST</bcp14> have the same timestamp.</
dd>
<dt/>
<dd>If a frame has the VP9 show_frame field set to 0 (i.e., it is
meant only to populate a reference buffer without being output), its
timestamp <bcp14>MAY</bcp14> alternatively be set to be the same as
the subsequent frame with show_frame equal to 1. (This will be
convenient for playing out pre-encoded content packaged with VP9
"superframes", which typically bundle show_frame==0 frames with a
subsequent show_frame==1 frame.) Every frame with show_frame==1,
however, <bcp14>MUST</bcp14> have a unique timestamp modulo the 2<sup>
32</sup>
wrap of the field.</dd>
</dl>
<t>The remaining RTP Fixed Header Fields (V, P, X, CC, sequence
number, SSRC, and CSRC identifiers) are used as specified in <xref
target="RFC3550" sectionFormat="of" section="5.1"
format="default"/>.</t>
</section> </section>
<section anchor="VP9payloadDescriptor" numbered="true" toc="default">
<name>VP9 Payload Descriptor</name>
<section anchor="VP9payloadDescriptor" title="VP9 Payload Descriptor"> <!--[rfced] Section 4.2: It seems the descriptions following Figure 3
<figure anchor="figureVP9payloadDescriptor"> apply to both Figures 2 and 3. If that is so, might a note of this appear
<preamble>In flexible mode (with the F bit below set to 1), the first somewhere earlier in that section for the ease of the reader?-->
octets
after the RTP header are the VP9 payload descriptor, with the followin
g
structure.</preamble>
<artwork><![CDATA[ <t keepWithNext="true">In flexible mode (with the F bit below set to 1),
the first octets
after the RTP header are the VP9 payload descriptor, with the followin
g
structure.</t>
<figure anchor="figureVP9payloadDescriptor" title="Flexible Mode Format
for VP9 Payload Descriptor">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 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">In non-flexible mode (with the F bit below set to
<figure anchor="figureVP9payloadDescriptorNonFlexible"> 0), 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" title="Non-flexib
<artwork><![CDATA[ le Mode Format for VP9 Payload Descriptor">
<artwork name="" type="" align="left" alt=""><![CDATA[
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>
<dl newline="false" spacing="normal">
<dt>I:</dt>
<dd>Picture ID (PID) present. When set to 1, the
<bcp14>OPTIONAL</bcp14> PID <bcp14>MUST</bcp14> be present after the
mandatory first octet and specified as below. Otherwise, PID
<bcp14>MUST NOT</bcp14> be present. If the V bit was set in the
stream's most recent start of a keyframe (i.e., the SS field was
present) and the F bit is set to 0 (i.e., non-flexible scalability
mode is in use), then this bit <bcp14>MUST</bcp14> be set on every
packet.</dd>
<dt>P:</dt>
<dd>Inter-picture predicted frame. When set to 0, the frame does
not utilize inter-picture prediction. In this case, up-switching to
a current spatial layer's frame is possible from a directly lower
spatial-layer frame. P <bcp14>SHOULD</bcp14> also be set to 0 when
encoding a layer synchronization frame in response to a <xref target="
RFC9627" format="default">Layer Refresh Request (LRR)</xref>
message (see <xref target="LRR" format="default"/>). When P is set
to 0, the TID field (described below) <bcp14>MUST</bcp14> also be
set to 0 (if present). Note that the P bit does not forbid
intra-picture, inter-layer prediction from earlier frames of the
same picture, if any.</dd>
<dt>L:</dt>
<t><list style="hanging"> <dd>Layer indices present. When set to 1, the one or two octets
<t hangText="I:">Picture ID (PID) present. When set to one, the following the mandatory first octet and the PID (if present) is as
OPTIONAL PID MUST be present after the mandatory first octet and described by "Layer indices" below. If the F bit (described below)
specified as below. Otherwise, PID MUST NOT be present. If the V bit is set to 1 (indicating flexible mode), then only one octet is
was set in the present for the layer indices. Otherwise, if the F bit is set to 0
stream's most recent start of a keyframe (i.e. the SS field was presen (indicating non-flexible mode), then two octets are present for the
t) and the F bit layer indices.</dd>
is set to 0 (i.e. non-flexible scalability mode is in use), <dt>F:</dt>
then this bit MUST be set on every packet.</t> <dd>Flexible mode. When set to 1, this indicates flexible mode; if th
e
<t hangText="P:">Inter-picture predicted frame. When set to zero, the P bit is also set to 1, then the octets following the mandatory
frame does not utilize inter-picture prediction. In this case, first octet, the PID, and layer indices (if present) are as
up-switching to a current spatial layer's frame is possible from direc described by "Reference indices" below. This bit <bcp14>MUST</bcp14>
tly only be set to 1 if the I bit is also set to 1; if the I bit is
lower spatial layer frame. P SHOULD also be set to zero when set to 0, then this bit <bcp14>MUST</bcp14> also be set to 0 and
encoding a layer synchronization frame in response to an <xref target= ignored by receivers. (Flexible mode's Reference indices are defined
'I-D.ietf-avtext-lrr'>LRR</xref> message (see <xref target='LRR'/>). as offsets from the Picture ID field, so they would have no meaning
When P is set to zero, the TID field (described below) MUST also if I were not set.) The value of the F bit <bcp14>MUST</bcp14>
be set to 0 (if present). Note that the P bit does not only change on the first packet of a key picture. A "key picture" is
forbid intra-picture, inter-layer prediction from earlier a picture whose base spatial-layer frame is a keyframe, and thus one w
frames of the same picture, if any.</t> hich
completely resets the encoder state. This packet will have its
<t hangText="L:">Layer indices present. When set to one, P bit equal to 0, SID or L bit (described below) equal to 0,
the one or two octets following the mandatory first octet and the PID and B bit (described below) equal to 1.</dd>
(if present) is as described by "Layer indices" below. If the F bit ( <dt>B:</dt>
described below) <dd>Start of a frame. This bit <bcp14>MUST</bcp14> be set to 1 if
is set to 1 (indicating flexible mode), then only one octet is present
for the
layer indices. Otherwise if the F bit is set to 0 (indicating non-flex
ible mode),
then two octets are present for the layer indices.</t>
<t hangText="F:">Flexible mode. F set to one indicates
flexible mode and if the P bit is also set to one, then the octets fol
lowing
the mandatory first octet, the PID, and layer indices (if present) are
as described by "Reference indices" below. This MUST only be set to 1
if the I
bit is also set to one; if the I bit is set to zero, then this MUST al
so be
set to zero and ignored by receivers. (Flexible mode's Reference indic
es are defined as offsets
from the Picture ID field, so they would have no meaning if I were not
set.)
The value of this F
bit MUST only change
on the first packet of a key picture. A key picture is a
picture whose base spatial layer frame is a key frame, and
which thus 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 1.</t>
<t hangText="B:">Start of a frame. MUST be set to 1 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 1. Note that t
frame might not be the first frame of a picture.</t> his
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>E:</dt>
<dd>End of a frame. This bit <bcp14>MUST</bcp14> be set to 1 for the
final
RTP packet of a VP9 frame, and 0 otherwise. This enables a RTP packet of a VP9 frame, and 0 otherwise. 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>V:</dt>
<t hangText="V:">Scalability structure (SS) data present. When set <dd>Scalability Structure (SS) data present. When set
to one, the OPTIONAL SS data MUST be present in the payload descriptor to 1, the <bcp14>OPTIONAL</bcp14> SS data <bcp14>MUST</bcp14> be prese
. nt in the payload descriptor.
Otherwise, the SS data MUST NOT be present.</t> Otherwise, the SS data <bcp14>MUST NOT</bcp14> be present.</dd>
<dt>Z:</dt>
<t hangText="Z:">Not a reference frame for upper spatial <dd>Not a reference frame for upper spatial layers. If set to 1,
layers. If set to 1, indicates that frames with higher indicates that frames with higher spatial layers SID+1 and greater
spatial layers SID+1 and greater of the current and following pictures of the current and following pictures do not depend on the current
do not depend on the current spatial layer SID frame. This spatial-layer SID frame. This enables a decoder that is targeting a
enables a decoder which is targeting a higher spatial layer higher spatial layer to know that it can safely discard this
to know that it can safely discard this packet's frame packet's frame without processing it, without having to wait for the
without processing it, without having to wait for the "D" D bit in the higher-layer frame (see below).</dd>
bit in the higher-layer frame (see below).</t> </dl>
</list></t>
<t>The mandatory first octet is followed by the extension data fields th at <t>The mandatory first octet is followed by the extension data fields th at
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">
extension flag. The field MUST be present if the I bit is equal to <dt>M:</dt>
one. If M is set, the PID field MUST contain 15 bits; otherwise, it MU
ST
contain 7 bits. See PID below.</t>
<t hangText="Picture ID (PID):">Picture ID represented in 7 or 15 bits <!-- [rfced] FYI: We've removed quotes from around certain bit names,
, e.g., ""D" bit" for consistency with similar uses in this
depending on the M bit. This is a running index of the pictures, where document. Please let us know if this is not preferred. Please
the also see our cluster-wide question regarding bit names prior to
sender increments the value by 1 for each picture it sends. (Note how reply.
ever that -->
because a middlebox can discard pictures where permitted by the scalab
ility structure, Picture IDs
as received by a receiver might not be contiguous.) This
field MUST be present if the I bit is equal to one. If M is set to zer
o,
7 bits carry the PID; else if M is set to one, 15 bits carry
the PID in network byte order.
The sender may choose between a 7- or 15-bit index. The PID SHOULD sta
rt on a
random number, and MUST wrap after reaching the maximum ID (0x7f or 0x
7fff depending on
the index size chosen). The receiver
MUST NOT assume that the number of bits in PID stay the same through t
he
session. If this field transitions from 7-bits to 15-bits, the value
is zero-extended
(i.e. the value after 0x6e is 0x006f); if the field transitions from 1
5 bits to 7 bits,
it is truncated (i.e. the value after 0x1bbe is 0xbf).
</t>
<t>In the non-flexible mode (when the F bit is set to 0), this PID is <dd>The most significant bit of the first octet is an extension
used flag. The field <bcp14>MUST</bcp14> be present if the I bit is equal
as an index to the picture group (PG) specified in the SS data below. to one. If M is set, the PID field <bcp14>MUST</bcp14> contain 15
In this mode, the bits; otherwise, it <bcp14>MUST</bcp14> contain 7 bits. See PID
PID of the key frame corresponds to the first specified frame in the below.</dd>
PG. Then subsequent PIDs are mapped to subsequently specified frames <dt>Picture ID (PID):</dt>
in <dd>Picture ID represented in 7 or 15 bits, depending on the M
the PG (modulo N_G, specified in the SS data below), respectively.</t> bit. This is a running index of the pictures, where the sender
increments the value by 1 for each picture it sends. (Note,
however, that because a middlebox can discard pictures where
permitted by the SS, Picture IDs as received by a
receiver might not be contiguous.) This field <bcp14>MUST</bcp14>
be present if the I bit is equal to one. If M is set to 0, 7 bits
carry the PID; else, if M is set to 1, 15 bits carry the PID in
network byte order. The sender may choose between a 7- or 15-bit
index. The PID <bcp14>SHOULD</bcp14> start on a random number and
<bcp14>MUST</bcp14> wrap after reaching the maximum ID (0x7f or
0x7fff depending on the index size chosen). The receiver <bcp14>MUST
NOT</bcp14> assume that the number of bits in the PID stays the same
through the session. If this field transitions from 7 bits to 15
bits, the value is zero-extended (i.e., the value after 0x6e is
0x006f); if the field transitions from 15 bits to 7 bits, it is
truncated (i.e., the value after 0x1bbe is 0xbf).
</dd>
<dt/>
<dd>In the non-flexible mode (when the F bit is set to 0), this PID
is used as an index to the PG specified in the SS
data below. In this mode, the PID of the keyframe corresponds to
the first specified frame in the PG. Then subsequent PIDs are
mapped to subsequently specified frames in the PG (modulo N_G,
specified in the SS data below), respectively.</dd>
<dt/>
<dd>All frames of the same picture <bcp14>MUST</bcp14> have the same
PID value.</dd>
<dt/>
<dd>Frames (and their corresponding pictures) with the VP9
show_frame field equal to 0 <bcp14>MUST</bcp14> have distinct PID
values from subsequent pictures with show_frame equal to 1. Thus, a
picture (as defined in this specification) is different than a VP9
superframe.</dd>
<dt/>
<dd>All frames of the same picture <bcp14>MUST</bcp14> have the same
value for show_frame.</dd>
<t>All frames of the same picture MUST have the same PID value. </t> <!--[rfced] Might a clarification of "This information" be helpful to the reader ?
<t>Frames (and their corresponding pictures) with the VP9 show_ Original:
frame field equal to 0 MUST
have distinct PID values from subsequent pictures with sh
ow_frame equal to 1. Thus,
a Picture as defined in this specification is different t
han a VP9 Superframe.</t>
<t>All frames of the same picture MUST have the same value for Layer indices: This information is optional but RECOMMENDED whenever
show_frame.</t> encoding with layers.
<t hangText="Layer indices:">This information is optional but RECOMMEN Perhaps:
DED
whenever encoding with layers. For both flexible and non-flexible mod
es,
one octet is used to specify a layer frame's temporal layer ID (TID) a
nd spatial layer ID (SID)
as shown both in <xref target="figureVP9payloadDescriptor"/> and <xref
target="figureVP9payloadDescriptorNonFlexible"/>.
Additionally, a bit (U) is used to indicate that the current frame is
a
"switching up point" frame. Another bit (D) is used to indicate wheth
er inter-layer
prediction is used for the current frame.</t>
<t>In the non-flexible mode (when the F bit is set to 0), another octe Layer indices: This field is optional but RECOMMENDED whenever
t is used encoding with layers.
to represent temporal layer 0 index (TL0PICIDX), as depicted in <xref -->
target="figureVP9payloadDescriptorNonFlexible"/>.
The TL0PICIDX is present so that all minimally required frames - the b
ase temporal layer frames - can be tracked.</t>
<t>The TID and SID fields indicate the temporal and spatial layers and <dt>Layer indices:</dt>
can help middleboxes and <dd>This information is optional but <bcp14>RECOMMENDED</bcp14>
endpoints quickly identify which layer a packet belongs to. whenever encoding with layers. For both flexible and non-flexible
modes, one octet is used to specify a layer frame's temporal-layer
ID (TID) and spatial-layer ID (SID) as shown both in <xref
target="figureVP9payloadDescriptor" format="default"/> and <xref
target="figureVP9payloadDescriptorNonFlexible" format="default"/>.
Additionally, a bit (U) is used to indicate that the current frame
is a "switching up point" frame. Another bit (D) is used to
indicate whether inter-layer prediction is used for the current
frame.</dd>
<dt/>
<dd>In the non-flexible mode (when the F bit is set to 0), another
octet is used to represent temporal-layer 0 index (TL0PICIDX), as
depicted in <xref target="figureVP9payloadDescriptorNonFlexible"
format="default"/>. The TL0PICIDX is present so that all minimally
required frames (the base temporal-layer frames) can be
tracked.</dd>
<dt/>
<dd>
<t>The TID and SID fields indicate the temporal and spatial layers
and can help middleboxes and endpoints quickly identify which
layer a packet belongs to.
<list style="hanging"> </t>
<t hangText="TID:">The temporal layer ID of current frame. In the c <dl newline="false" spacing="normal">
ase of non-flexible mode, <dt>TID:</dt>
if PID is mapped to a picture in a specified PG, then <dd>The temporal-layer ID of the current frame. In the case of
the value of TID MUST match the corresponding TID value of the mappe non-flexible mode, if a PID is mapped to a picture in a specified
d picture in the PG.</t> PG, then the value of the TID <bcp14>MUST</bcp14> match the
corresponding TID value of the mapped picture in the PG.</dd>
<dt>U:</dt>
<t hangText="U:">Switching up point. If this bit is set to 1 for th <!--[rfced] If TID expands to "temporal layer ID", does this text say
e current picture with temporal "with TID equal to TID"? Please clarify.
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 Original:
frames with spatial layer SID > 0 If this bit is set to 1 for the current picture with temporal layer ID
may be dependent on decoded spatial layer SID-1 frame within the sam equal to TID...
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 <dd>Switching up point. If this bit is set to 1 for the current
is only present picture with a temporal-layer ID equal to TID, then "switch up"
in the non-flexible mode (F = 0). This is a running index for the t to a higher frame rate is possible as subsequent higher
emporal temporal-layer pictures will not depend on any picture before
base layer pictures, i.e., the pictures with TID set to 0. If TID i the current picture (in coding order) with temporal-layer ID
s larger than 0, greater than TID.</dd>
TL0PICIDX indicates which temporal base layer picture the current pi <dt>SID:</dt>
cture depends on. TL0PICIDX MUST be <dd>The spatial-layer ID of the current frame. Note that frames
incremented by 1 when TID is equal to 0. The index SHOULD start on with spatial-layer SID > 0 may be dependent on decoded
a random number, and MUST restart spatial-layer SID-1 frame within the same picture. Different
at 0 after reaching the maximum number 255.</t> frames of the same picture <bcp14>MUST</bcp14> have distinct
</list></t> spatial-layer IDs, and frames' spatial layers
<bcp14>MUST</bcp14> appear in increasing order within the
frame.</dd>
<dt>D:</dt>
<dd>Inter-layer dependency is used. D <bcp14>MUST</bcp14> be
set to 1 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 0. For the
base-layer frame (with SID equal to 0), the D bit
<bcp14>MUST</bcp14> be set to 0.</dd>
<dt>TL0PICIDX:</dt>
<dd>8 bits temporal-layer zero index. 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 0. If the TID is larger than 0, TL0PICIDX indicates which
temporal base-layer picture the current picture depends on.
TL0PICIDX <bcp14>MUST</bcp14> be incremented by 1 when the TID is
equal to 0. The index <bcp14>SHOULD</bcp14> start on a random
number and <bcp14>MUST</bcp14> restart at 0 after reaching the
maximum number 255.</dd>
</dl>
</dd>
<dt>Reference indices:</dt>
<dd>
<t>When P and F are both set to 1, 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 0,
then no reference index is specified.
</t>
<dl newline="false" spacing="normal">
<dt>P_DIFF:</dt>
<dd>The reference index (in 7 bits) specified as the relative
PID from the current picture. For example, when P_DIFF=3 on a
packet containing the picture with PID 112 means that the
picture refers back to the picture with PID 109. This
calculation is done modulo the size of the PID field, i.e.,
either 7 or 15 bits. A P_DIFF value of 0 is invalid.</dd>
<dt>N:</dt>
<dd>1 if there is additional P_DIFF following the current P_DIFF.<
/dd>
</dl>
</dd>
</dl>
<t hangText="Reference indices:">When P and F are both set to one, ind <section anchor="VP9payloadDescriptorSS" numbered="true" toc="default">
icating a non-key frame in <name>Scalability Structure (SS)</name>
flexible mode, then at least <t>The SS data describes the resolution of
one reference index MUST be specified as below. Additional reference each frame within a picture as well as the inter-picture
indices (total of up to dependencies for a PG. If the VP9 payload
3 reference indices are allowed) may be specified using the N bit belo descriptor's V bit is set, the SS data is present in the position
w. When either P or F is indicated in Figures <xref format="counter" target="figureVP9payloadDe
set to zero, then no reference index is specified. scriptor"/> and <xref target="figureVP9payloadDescriptorNonFlexible" format="cou
<list style="hanging"> nter"/>.</t>
<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) <figure anchor="figureVP9ScalabilityStructure" title="VP9 Scalability
:"> Structure">
<t>The scalability structure (SS) data describes the resolution of <artwork name="" type="" align="left" alt=""><![CDATA[
each frame within a picture as well as the inter-picture dependencies
for a picture group (PG). If the VP9 payload descriptor's "V"
bit is set, the SS data is present in the position indicated in
<xref target="figureVP9payloadDescriptor"/> and <xref target="figureVP9p
ayloadDescriptorNonFlexible"/>.</t>
<figure anchor="figureVP9ScalabilityStructure">
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
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>
<t><list style="hanging">
<t hangText="N_S:">N_S + 1 indicates the number of spatial
layers present in the VP9 stream.</t>
<t hangText="Y:">Each spatial layer's frame resolution present.
When set to one, the OPTIONAL WIDTH (2 octets) and HEIGHT
(2 octets) MUST be present for each layer frame. Otherwise, the
resolution MUST NOT be present.</t>
<t hangText="G:">PG description present flag.</t>
<t hangText="-:">Bit reserved for future use. MUST be set to
zero and MUST be ignored by the receiver.</t>
<t hangText="N_G:">N_G indicates the number of pictures in a
Picture Group (PG).
If N_G is greater than 0, then the SS data allows
the inter-picture dependency structure of the VP9 stream to
be pre-declared, rather than indicating it on the fly with
every packet. If N_G is greater than 0, then for N_G
pictures in the PG, each picture's temporal layer ID (TID), switch up
point (U),
and the Reference indices (P_DIFFs) are specified.</t>
<t>The first picture specified in the PG MUST have TID set to 0.</t>
<t>G set to 0 or N_G set to 0 indicates that either there is only one
temporal
layer (for non-flexible mode) or no fixed inter-picture dependency inf
ormation is present
(for flexible mode) going forward in the bitstream.</t>
<t>Note that for a given picture, all frames follow the <!--[rfced] We note that not all fields that appear in Figure 4 are
same inter-picture dependency structure. However, the frame rate described following it. Please review and let us know if text
of each spatial layer can be different from each other and this can (or a pointer to where the reader can get more information on
be described with the use of the D bit described above. The these fields) should be added.
specified dependency structure in the SS data MUST be for the highest
frame rate layer.</t>
</list></t>
<t>In a scalable stream sent with a fixed pattern, the SS data -->
SHOULD be included in the first packet of every key frame. This is a pac <dl newline="false" spacing="normal">
ket <dt>N_S:</dt>
with P bit equal to zero, SID or L bit equal to zero, and B bit equal to <dd>N_S + 1 indicates the number of spatial
1. layers present in the VP9 stream.</dd>
The SS data MUST only be changed on the picture that corresponds to the <dt>Y:</dt>
first picture specified in the previous SS data's PG <dd>Each spatial layer's frame resolution is present.
(if the previous SS data's N_G was greater than 0).</t> When set to 1, the <bcp14>OPTIONAL</bcp14> WIDTH (2 octets) and HEIGHT
(2 octets) <bcp14>MUST</bcp14> be present for each layer frame. Other
wise, the
resolution <bcp14>MUST NOT</bcp14> be present.</dd>
<dt>G:</dt>
<dd>The PG description present flag.</dd>
<dt>-:</dt>
<dd>A bit reserved for future use. It <bcp14>MUST</bcp14> be set
to 0 and <bcp14>MUST</bcp14> be ignored by the receiver.</dd>
<dt>N_G:</dt>
<dd>N_G indicates the number of pictures in a PG.
If N_G is greater than 0, then the SS data allows the
inter-picture dependency structure of the VP9 stream to be
pre-declared, rather than indicating it on the fly with every
packet. If N_G is greater than 0, then for N_G pictures in the
PG, each picture's temporal-layer ID (TID), switch up point (U),
and Reference indices (P_DIFFs) are specified.</dd>
<dt/>
<dd>The first picture specified in the PG <bcp14>MUST</bcp14> have a
TID set to 0.</dd>
<dt/>
<dd>G set to 0 or N_G set to 0 indicates that either there is only
one temporal layer (for non-flexible mode) or no fixed
inter-picture dependency information is present (for flexible
mode) going forward in the bitstream.</dd>
<dt/>
<dd>Note that for a given picture, all frames follow the same
inter-picture dependency structure. However, the frame rate of
each spatial layer can be different from each other; this can
be described with the use of the D bit described above. The
specified dependency structure in the SS data <bcp14>MUST</bcp14>
be for the highest frame rate layer.</dd>
</dl>
<t>In a scalable stream sent with a fixed 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 0, SID or L bit equal
to 0, and B bit equal to 1. 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 0).</t>
</section>
</section> </section>
</section> <section numbered="true" toc="default">
<name>Frame Fragmentation</name>
<section title="Frame Fragmentation"> <t>VP9 frames are fragmented into packets in RTP sequence number
<t>VP9 frames are fragmented into packets, in RTP sequence order: beginning with a packet with the B bit set and ending with a
number order, beginning with a packet with the E bit set. There is no mechanism for finer-grained
packet with the B bit set, and ending with a packet with the access to parts of a VP9 frame.</t>
E bit set. There is no mechanism for finer-grained
access to parts of a VP9 frame.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Scalable encoding considerations"> <name>Scalable Encoding Considerations</name>
<t>In addition to the use of reference frames, VP9 has several
<t>In addition to the use of reference frames, 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>Due to the requirements of scalable streams, a VP9 encoder
<t>Due to the requirements of scalable streams, 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>For spatially scalable streams, this means that
<t>For spatially-scalable streams, this means 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="default">
<name>Examples of VP9 RTP Stream</name>
<section title="Examples of VP9 RTP Stream"> <section numbered="true" toc="default">
<section title="Reference picture use for scalable structure"> <name>Reference Picture Use for Scalable Structure</name>
<t>As discussed in <xref target="mediaFormatDescription" format="defau
<t>As discussed in <xref target="mediaFormatDescription"/>, the lt"/>, 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">
<texttable title="Example scalability structure"> <name>Example Scalability Structure</name>
<thead>
<ttcol align="center">Temporal</ttcol> <tr>
<ttcol align="center">Spatial</ttcol> <th align="center">Temporal</th>
<ttcol align="center">References</ttcol> <th align="center">Spatial</th>
<ttcol align="center">Updates</ttcol> <th align="center">References</th>
<c>0</c><c>0</c><c>0</c><c>0</c> <th align="center">Updates</th>
<c>0</c><c>1</c><c>0,1</c><c>1</c> </tr>
<c>0</c><c>2</c><c>1,2</c><c>2</c> </thead>
<c>2</c><c>0</c><c>0</c><c>6</c> <tbody>
<c>2</c><c>1</c><c>1,6</c><c>7</c> <tr>
<c>2</c><c>2</c><c>2,7</c><c>-</c> <td align="center">0</td>
<c>1</c><c>0</c><c>0</c><c>3</c> <td align="center">0</td>
<c>1</c><c>1</c><c>1,3</c><c>4</c> <td align="center">0</td>
<c>1</c><c>2</c><c>2,4</c><c>5</c> <td align="center">0</td>
<c>2</c><c>0</c><c>3</c><c>6</c> </tr>
<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> <td align="center">0</td>
<td align="center">1</td>
</texttable> <td align="center">0,1</td>
<td align="center">1</td>
<t>This structure is constructed such that the "U" bit can </tr>
<tr>
<td align="center">0</td>
<td align="center">2</td>
<td align="center">1,2</td>
<td align="center">2</td>
</tr>
<tr>
<td align="center">2</td>
<td align="center">0</td>
<td align="center">0</td>
<td align="center">6</td>
</tr>
<tr>
<td align="center">2</td>
<td align="center">1</td>
<td align="center">1,6</td>
<td align="center">7</td>
</tr>
<tr>
<td align="center">2</td>
<td align="center">2</td>
<td align="center">2,7</td>
<td align="center">-</td>
</tr>
<tr>
<td align="center">1</td>
<td align="center">0</td>
<td align="center">0</td>
<td align="center">3</td>
</tr>
<tr>
<td align="center">1</td>
<td align="center">1</td>
<td align="center">1,3</td>
<td align="center">4</td>
</tr>
<tr>
<td align="center">1</td>
<td align="center">2</td>
<td align="center">2,4</td>
<td align="center">5</td>
</tr>
<tr>
<td align="center">2</td>
<td align="center">0</td>
<td align="center">3</td>
<td align="center">6</td>
</tr>
<tr>
<td align="center">2</td>
<td align="center">1</td>
<td align="center">4,6</td>
<td align="center">7</td>
</tr>
<tr>
<td align="center">2</td>
<td align="center">2</td>
<td align="center">5,7</td>
<td align="center">-</td>
</tr>
</tbody>
</table>
<t>This structure is constructed such that the U bit can
always be set.</t> always be set.</t>
</section>
</section> </section>
</section>
</section> </section>
<section anchor="Feedback" title="Feedback Messages and Header Extensions"> <section anchor="Feedback" numbered="true" toc="default">
<section anchor="RPSI" title="Reference Picture Selection Indication (RPSI <name>Feedback Messages and Header Extensions</name>
)"> <section anchor="RPSI" numbered="true" toc="default">
<!--[rfced] Section 5.1 is titled "Reference Picture Selection
Indication (RPSI)". The first sentence of this section uses
"reference picture selection index". Please review if "index" is
correct or if it should be made "indication" (or vice versa).-->
<name>Reference Picture Selection Indication (RPSI)</name>
<t>The reference picture selection index is a payload-specific <t>The reference picture selection index 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
simply the (7 or 15 bit) Picture ID of the received frame.</t> target="RFC4585" format="default"/>) is simply the (7- or 15-bit)
Picture ID of the received frame.</t>
<t>Note: because all frames of the same picture must have the <!--[rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container
for content that is semantically less important or tangential to
the content that surrounds it"
(https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-aside-2).
-->
<t>Note: because all frames of the same 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>
</section> </section>
<section anchor="FIR" numbered="true" toc="default">
<section title='Full Intra Request (FIR)' anchor="FIR"> <name>Full Intra Request (FIR)</name>
<t>The <xref target="RFC5104" format="default">Full Intra Request (FIR)<
<t>The <xref target='RFC5104'>Full Intra Request (FIR)</xref> /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>Upon receipt of a FIR request, a VP9 sender <bcp14>MUST</bcp14>
<t>Upon receipt of an FIR request, a VP9 sender MUST send a send a picture with a keyframe for its spatial-layer 0 layer frame and
picture with a keyframe for its spatial layer 0 layer then send frames without inter-picture prediction (P=0) for any
frame, and then send frames without inter-picture prediction higher-layer frames.</t>
(P=0) for any higher layer frames.</t> </section>
<section anchor="LRR" numbered="true" toc="default">
</section> <name>Layer Refresh Request (LRR)</name>
<t>The <xref target="RFC9627" format="default">Layer Refresh Request
<section title="Layer Refresh Request (LRR)" anchor="LRR"> (LRR)</xref> allows a receiver to request a single layer of a
<t>The <xref target="I-D.ietf-avtext-lrr">Layer Refresh Request ( spatially or temporally encoded stream to be refreshed without
LRR)</xref> necessarily affecting the stream's other layers.</t>
allows a receiver to request a single layer of a spatially or <figure anchor="figureLRRIndexFormat" title="LRR Index Format">
temporally encoded stream to be refreshed, without necessarily <artwork name="" type="" align="left" alt=""><![CDATA[
affecting the stream's other layers.</t>
<figure anchor="figureLRRIndexFormat">
<artwork><![CDATA[
+---------------+---------------+ +---------------+---------------+
|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><xref target="figureLRRIndexFormat" format="default"/> shows the form
<t><xref target="figureLRRIndexFormat"/> shows the format at
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 0 on transmission and ignore
reception. See <xref target="VP9payloadDescriptor"/> for d on
reception. See <xref target="VP9payloadDescriptor" format="defau
lt"/> for
details on the TID and SID fields.</t> details on the TID and SID fields.</t>
<t>Identification of a layer refresh frame can be derived from the <!-- [rfced] In the following sentences:
reference IDs of each frame by backtracking the dependency chain
until reaching a point where only decodable frames are being
referenced. Therefore it's recommended for both the
flexible and the non-flexible mode that, when switching up points are
being encoded in response to a LRR, those packets should contain
layer indices and the reference field(s) so that the decoder or a
<xref target='RFC7667'>selective forwarding
middleboxes</xref> can make this derivation.</t>
<t>Example:</t> a) does the receiver want to upgrade to {2,1}? How might we clarify
<t>LRR {1,0}, {2,1} is sent by an MCU when it is currently "which"?
b) please review the use of commas between the braced values. Is our
suggestion correct?
Original:
LRR {1,0}, {2,1} is sent by an MCU when it is currently relaying
{1,0} to a receiver and which 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 {1,0}, or {0,0}.
Perhaps:
LRR {1,0} {2,1} is sent by an 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 {1,0} or {0,0}.
-->
<t>Identification of a layer refresh frame can be derived from
the reference IDs of each frame by backtracking the dependency
chain until reaching a point where only decodable frames are
being referenced. Therefore, it's recommended for both the
flexible and the non-flexible mode that, when switching up
points are being encoded in response to an LRR, those packets
contain layer indices and the reference field or fields so
that the decoder or <xref target="RFC7667"
format="default">selective forwarding middleboxes</xref> can
make this derivation.</t>
<t>Example:</t>
<t>LRR {1,0}, {2,1} is sent by a Multipoint Control
Unit (MCU) when it is currently
relaying {1,0} to a receiver and which wants to upgrade to relaying {1,0} to a receiver and which wants to upgrade to
{2,1}. In response the encoder should encode the next frames {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>In the non-flexible mode, periodic upgrade frames can be defined by
the layer structure of the SS; thus, periodic upgrade frames can be
automatically identified by the Picture ID.</t>
</section>
<t>In the non-flexible mode, periodic upgrade frames can be </section>
defined by the layer structure of the SS, thus periodic upgrade
frames can be automatically identified by the picture ID.</t>
</section>
</section> <section anchor="payloadFormatParameters" numbered="true" toc="default">
<section anchor="payloadFormatParameters" <!--[rfced] In the following, please review the use of "value"
title="Payload Format Parameters"> (singular) and "receivers" (not possessive?).
<t>This payload format has three optional parameters, "max-fr", "max-fs",
and "profile-id".</t>
<t>The max-fr and max-fs Original:
parameters are used to signal the capabilities of a receiver ...where a media sender does not have media available that fits within
implementation. If the implementation is willing to a receivers max-fs and max-fr value;...
receive media, both parameters MUST be provided. These parameters MU
ST
NOT be used for any other purpose. A media sender SHOULD NOT send
media with a frame rate or frame size exceeding the max-fr and max-f
s
values signaled. (There may be scenarios, such as pre-encoded
media or <xref target='RFC7667'>selective forwarding
middleboxes</xref>, where a media sender does not have media availab
le
that fits within a receivers max-fs and max-fr value; in such
scenarios, a sender MAY exceed the signaled values.)
<list style="hanging">
<t hangText="max-fr:">The value of max-fr is an integer
indicating the maximum frame rate in units of frames per
second that the decoder is capable of decoding.</t>
<t hangText="max-fs:">The value of max-fs is an integer Perhaps:
...where a media sender does not have media available that fits within
a receiver's max-fs and max-fr values;...
-->
<name>Payload Format Parameters</name>
<t>This payload format has three optional parameters: max-fr,
max-fs, and profile-id.</t>
<t>The max-fr and max-fs parameters are used to signal the capabilities
of a receiver implementation. If the implementation is willing to
receive media, both parameters <bcp14>MUST</bcp14> be provided. These
parameters <bcp14>MUST NOT</bcp14> be used for any other purpose. A
media sender <bcp14>SHOULD NOT</bcp14> send media with a frame rate or
frame size exceeding the max-fr and max-fs values signaled. (There may
be scenarios, such as pre-encoded media or <xref target="RFC7667"
format="default">selective forwarding middleboxes</xref>, where a media
sender does not have media available that fits within a receiver's
max-fs and max-fr value; in such scenarios, a sender <bcp14>MAY</bcp14>
exceed the signaled values.)
</t>
<dl newline="false" spacing="normal">
<dt>max-fr:</dt>
<dd>The value of max-fr is an integer
indicating the maximum frame rate in units of frames per
second that the decoder is capable of decoding.</dd>
<dt>max-fs:</dt>
<dd>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/>
<t>The decoder is capable of decoding this frame size as long <!--[rfced] Might adding "each" to the following text be helpful for
the reader? Or is the intention that the width and height be
taken together? (Same question for the last sentence of this
paragraph.)
Original:
The decoder is capable of decoding this frame size as long as the
width and height of the frame in macroblocks are less than
int(sqrt(max-fs * 8)) - 8))...
Perhaps:
The decoder is capable of decoding this frame size as long as the
width and height of the frame in macroblocks are each less than
int(sqrt(max-fs * 8)) - 8))...
-->
<dd>The decoder is capable of decoding this frame size as long
as the width and height of the frame in macroblocks are less as the width and height of the frame in macroblocks are less
than int(sqrt(max-fs * 8)) - for instance, a max-fs of 1200 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>profile-id:</dt>
<t hangText="profile-id:">The value of profile-id is an integer <dd>The value of profile-id is an integer indicating the default
indicating the default coding profile, the subset of coding coding profile (the subset of coding tools that may have been used to
tools that may have been used to generate the stream or that the generate the stream or that the receiver supports). <xref
receiver supports). <xref target="TableOfProfileIds"/> lists all target="TableOfProfileIds" format="default"/> lists all of the
of the profiles defined in section 7.2 of <xref target="VP9-BITST profiles defined in Section 7.2 of <xref target="VP9-BITSTREAM"
REAM"/> format="default"/> and the corresponding integer values to be
and the corresponding integer values to be used.</t> used.</dd>
<dt/>
<t>If no profile-id is present, Profile 0 MUST be inferred. (The <dd>If no profile-id is present, Profile 0 <bcp14>MUST</bcp14> be inferr ed. (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/>
<t>Informative note: See <xref target="TableOfProfiles"/> for cap <dd>Informative note: See <xref target="TableOfProfiles"
abilities format="default"/> for capabilities of coding profiles defined in Sectio
of coding profiles defined in section 7.2 of <xref target="VP9-BI n 7.2 of
TSTREAM"/>.</t> <xref target="VP9-BITSTREAM" format="default"/>.</dd>
</list></t> </dl>
<t>A receiver <bcp14>MUST</bcp14> ignore any parameter unspecified in this
<t>A receiver MUST ignore any parameter unspecified in this specification.</t>
specification.</t>
<texttable anchor="TableOfProfileIds" title="Table of profile-id <!--[rfced] Please note that we have shortened the title of Table 2
integer values representing the VP9 profile corresponding to the set of and rephrased to avoid awkward hyphenation. Please review and
coding tools supported."> let us know any objections.
<ttcol align="center">Profile</ttcol>
<ttcol align="center">profile-id</ttcol>
<c>0</c><c>0</c>
<c>1</c><c>1</c>
<c>2</c><c>2</c>
<c>3</c><c>3</c>
</texttable>
<texttable anchor="TableOfProfiles" title="Table of profile Original:
capabilities."> Table of profile-id integer values representing the VP( profile
<ttcol align="center">Profile</ttcol> corresponding to the set of coding tools supported Current: profile-id
<ttcol align="center">Bit Depth</ttcol> to VP9 Profile Integer Comparison
<ttcol align="center">SRGB Colorspace</ttcol>
<ttcol align="center">Chroma Subsampling</ttcol>
<c>0</c><c>8</c><c>No</c><c>YUV 4:2:0</c>
<c>1</c><c>8</c><c>Yes</c><c>YUV 4:2:2,4:4:0 or 4:4:4</c>
<c>2</c><c>10 or 12</c><c>No</c><c>YUV 4:2:0</c>
<c>3</c><c>10 or 12</c><c>Yes</c><c>YUV 4:2:2,4:4:0 or 4:4:4</c>
</texttable>
<section anchor="SDPParameters" title="SDP Parameters"> Current:
<section title="Mapping of Media Subtype Parameters to SDP"> Comparison of profile-id to VP9 Profile Integer
<t>The media type video/VP9 string is mapped to fields in the -->
Session Description Protocol (SDP) <xref target="RFC8866"/> as
follows: <list style="symbols">
<t>The media name in the "m=" line of SDP MUST be video.</t>
<t>The encoding name in the "a=rtpmap" line of SDP MUST be VP9 <table anchor="TableOfProfileIds" align="center">
(the media subtype).</t> <name>Comparison of profile-id to VP9 Profile Integer</name>
<thead>
<tr>
<th align="center">Profile</th>
<th align="center">profile-id</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">0</td>
<td align="center">0</td>
</tr>
<tr>
<td align="center">1</td>
<td align="center">1</td>
</tr>
<tr>
<td align="center">2</td>
<td align="center">2</td>
</tr>
<tr>
<td align="center">3</td>
<td align="center">3</td>
</tr>
</tbody>
</table>
<table anchor="TableOfProfiles" align="center">
<name>Profile Capabilities</name>
<thead>
<tr>
<th align="center">Profile</th>
<th align="center">Bit Depth</th>
<th align="center">SRGB Colorspace</th>
<th align="center">Chroma Subsampling</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">0</td>
<td align="center">8</td>
<td align="center">No</td>
<td align="center">YUV 4:2:0</td>
</tr>
<tr>
<td align="center">1</td>
<td align="center">8</td>
<td align="center">Yes</td>
<td align="center">YUV 4:2:2,4:4:0 or 4:4:4</td>
</tr>
<tr>
<td align="center">2</td>
<td align="center">10 or 12</td>
<td align="center">No</td>
<td align="center">YUV 4:2:0</td>
</tr>
<tr>
<td align="center">3</td>
<td align="center">10 or 12</td>
<td align="center">Yes</td>
<td align="center">YUV 4:2:2,4:4:0 or 4:4:4</td>
</tr>
</tbody>
</table>
<t>The clock rate in the "a=rtpmap" line MUST be 90000.</t> <section anchor="SDPParameters" numbered="true" toc="default">
<name>SDP Parameters</name>
<section numbered="true" toc="default">
<name>Mapping of Media Subtype Parameters to SDP</name>
<t>The parameters "max-fr" and "max-fs" MUST be included in <t>The media type video/vp9 string is mapped to fields in the
Session Description Protocol (SDP) <xref target="RFC8866" format="defa
ult"/> as
follows: </t>
<ul spacing="normal">
<li>The media name in the "m=" line of SDP <bcp14>MUST</bcp14> be vi
deo.</li>
<li>The encoding name in the "a=rtpmap" line of SDP
<bcp14>MUST</bcp14> be VP9 (the media subtype).</li>
<li>The clock rate in the "a=rtpmap" line <bcp14>MUST</bcp14> be 900
00.</li>
<li>The parameters max-fr and max-fs <bcp14>MUST</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>The <bcp14>OPTIONAL</bcp14> parameter profile-id, when present,
<t>The OPTIONAL parameter profile-id, when present, SHOULD be <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="default">
<name>Example</name>
<t>An example of media representation in SDP is as follows:</t> <t>An example of media representation in SDP is as follows:</t>
<sourcecode type="sdp"><![CDATA[m=video 49170 RTP/AVPF 98
<figure>
<artwork>m=video 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="default">
<section title="Offer/Answer Considerations"> <name>Offer/Answer Considerations</name>
<t>When VP9 is offered over RTP using SDP in an Offer/Answer model <t>When VP9 is offered over RTP using SDP in an Offer/Answer model
<xref target="RFC3264"/> for negotiation for unicast usage, the follow <xref target="RFC3264" format="default"/> for negotiation for unicast
ing usage, the following
limitations and rules apply: <list style="symbols"> limitations and rules apply: </t>
<t>The parameter identifying a media format configuration for VP9 i <ul spacing="normal">
s <li>The parameter identifying a media format configuration for VP9 i
profile-id. This media format configuration parameter MUST be used s
symmetrically; that is, the answerer MUST either maintain this 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>The max-fr and max-fs parameters are used declaratively to
<t>The max-fr and max-fs parameters are used 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>To simplify the handling and matching of these configurations, t
<t>To simplify the handling and matching of these configurations, he
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"/>. An answer or subsequent offer
MUST NOT contain the payload type number used in the offer unless t <bcp14>MUST NOT</bcp14> contain the payload type number used in the
he 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" title="Media Type Definition"> <section anchor="mediaTypeRegistration" numbered="true" toc="default">
<t>This registration is done using the template defined in <xref <name>Media Type Definition</name>
target="RFC6838"/> and following <xref target="RFC4855"/>. <list <t>This registration uses the template defined in <xref target="RFC6838" f
style="hanging"> ormat="default"/> and following <xref target="RFC4855" format="default"/>. </t>
<t hangText="Type name:">video</t>
<t hangText="Subtype name:">VP9</t>
<t hangText="Required parameters:">N/A.</t>
<t hangText="Optional parameters:"><vspace blankLines="0"/> <!--[rfced] Please note that after AUTH48 concludes, we will
There are three optional parameters, "max-fr", "max-fs", and "profil communicate any changes to the media type template in Section 7
e-id". to IANA for corresponding updates to
See <xref target='payloadFormatParameters' /> for their definition. https://www.iana.org/assignments/media-types/video/VP9 to be
</t> made.-->
<t hangText="Encoding considerations:"><vspace blankLines="0"/> <dl newline="false" spacing="normal">
<dt>Type name:</dt>
<dd>video</dd>
<dt>Subtype name:</dt>
<dd>VP9</dd>
<dt>Required parameters:</dt>
<dd>N/A</dd>
<dt>Optional parameters:</dt>
<dd>
There are three optional parameters: max-fr, max-fs, and profile-id.
See <xref target="payloadFormatParameters" format="default"/> for th
eir definition.
</dd>
<dt>Encoding considerations:</dt>
<dd>
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="default"/>.</dd>
<dt>Security considerations:</dt>
<dd>
<t>See <xref target="securityConsiderations" format="default"/> of RFC
9628. </t>
<t hangText="Security considerations:">See <xref </dd>
target="securityConsiderations"/> of RFC xxxx. <vspace <dt>Interoperability considerations:</dt>
blankLines="0"/> [RFC Editor: Upon publication as an RFC, please <dd>None</dd>
replace "XXXX" with the number assigned to this document and <dt>Published specification:</dt>
remove this note.]</t> <dd>
<t>VP9 bitstream format <xref target="VP9-BITSTREAM" format="default"/
> and RFC 9628. </t>
<t hangText="Interoperability considerations:">None.</t> </dd>
<dt>Applications that use this media type:</dt>
<dd> For example, video over IP, video
conferencing.</dd>
<dt>Fragment identifier considerations:</dt>
<dd>N/A</dd>
<dt>Additional information:</dt>
<dd>None</dd>
<dt>Person &amp; email address to contact for further information:</dt>
<dd><t><contact fullname="Jonathan Lennox"/> &lt;jonathan.lennox@8x8.com
&gt;</t></dd>
<dt>Intended usage:</dt>
<dd>COMMON</dd>
<dt>Restrictions on usage:</dt>
<dd> This media type depends on RTP framing; hence, it is only defined
for transfer via RTP <xref target="RFC3550" format="default"/>.</dd>
<dt>Author:</dt>
<dd><t><contact fullname="Jonathan Lennox"/> &lt;jonathan.lennox@8x8.com
&gt;</t></dd>
<t hangText="Published specification:">VP9 bitstream format <xref <!--[rfced] Please review the entry for "Change Controller" in Section
target="VP9-BITSTREAM"/> and RFC XXXX. <vspace blankLines="0"/> [RFC 7. While we see similar text for the vp8 and vc2 entries, we want to
Editor: Upon publication as an RFC, please replace "XXXX" with the confirm that this entry has been reviewed with the following in
number assigned to this document and remove this note.] <vspace mind from
blankLines="0"/></t> https://www.iana.org/help/protocol-registration:
<t hangText="Applications which use this media type:"><vspace "The IESG shouldn't be listed as a change controller unless the
blankLines="0"/> For example: Video over IP, video RFC that created the registry (e.g. port numbers, XML namespaces
conferencing.</t> and schemas) requires it. The IETF should be named instead."
<t hangText="Fragment identifier considerations:">N/A.</t > -->
<t hangText="Additional information:">None.</t> <dt>Change controller:</dt>
<dd> IETF
AVTCore Working Group delegated from the IESG.</dd>
</dl>
</section>
<section anchor="securityConsiderations" numbered="true" toc="default">
<name>Security Considerations</name>
<t>RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification <xref target="RFC3550" format="default"/>, and in any
applicable RTP profile such as <xref target="RFC3551"
format="default">RTP/AVP</xref>, <xref target="RFC4585"
format="default">RTP/AVPF</xref>, <xref target="RFC3711"
format="default">RTP/SAVP</xref>, or <xref target="RFC5124"
format="default">RTP/SAVPF</xref>. However, as "<xref target="RFC7202" fo
rmat="title"/>" <xref target="RFC7202"
format="default"></xref> discusses, it is not an RTP
payload format's responsibility to discuss or mandate what solutions are
used to meet the basic security goals like confidentiality, integrity,
and source authenticity for RTP in general. This responsibility lies with
anyone using RTP in an application. They can find guidance on available
security mechanisms in "<xref target="RFC7201" format="title"/> <xref targ
et="RFC7201" format="default"></xref>. Applications <bcp14>SHOULD</bcp14>
use one or more appropriate strong security mechanisms.</t>
<t>Implementations of this RTP payload format need to take appropriate
security considerations into account. It is extremely important for the
decoder to be robust against malicious or malformed payloads and ensure
that they do not cause the decoder to overrun its allocated memory or
otherwise misbehave. An overrun in allocated memory could lead to
arbitrary code execution by an attacker. The same applies to the
encoder, even though problems in encoders are (typically) rarer.</t>
<t>This RTP payload format and its media decoder do not exhibit any
significant non-uniformity in the receiver-side computational complexity
for packet processing; thus, they are unlikely to pose a denial-of-service
threat due to the receipt of pathological data. Nor does the RTP payload
format contain any active content.</t>
</section>
<section anchor="congestionControl" numbered="true" toc="default">
<name>Congestion Control</name>
<t>Congestion control for RTP <bcp14>SHALL</bcp14> be used in accordance
with <xref target="RFC3550" format="default"/>, and with any
applicable RTP profile, e.g., <xref target="RFC3551"
format="default"/>. The congestion control mechanism can, in a real-time
encoding scenario, adapt the transmission rate by instructing the
encoder to encode at a certain target rate. Media-aware network elements
<bcp14>MAY</bcp14> use the information in the VP9 payload descriptor in
<xref target="VP9payloadDescriptor" format="default"/> to identify
non-reference frames and discard them in order to reduce network
congestion. Note that discarding of non-reference frames cannot be done
if the stream is encrypted (because the non-reference marker is
encrypted).</t>
</section>
<section anchor="IANAConsiderations" numbered="true" toc="default">
<name>IANA Considerations</name>
<t <!--[rfced] Should any further information on the IANA Considerations
hangText="Person &amp; email address to contact for further informat for the "RTP Payload Format Media Types" registry be given?
ion:"><vspace
blankLines="0"/> Jonathan Lennox &lt;jonathan.lennox@8x8.com&gt;</t>
<t hangText="Intended usage:">COMMON</t> Perhaps:
The media type has also been added to the "RTP Payload Format Media
Types" subregistry of th e"Real-Time Transport Protocol (RTP)
Parameters" registry as follows:
<t hangText="Restrictions on usage:"><vspace blankLines="0"/> This Media Type: video
media type depends on RTP framing, and hence is only defined for Subtype: VP9
transfer via RTP <xref target="RFC3550"/>.</t> Clock Rate (Hz): 90000
Reference: RFC 9628
-->
<t hangText="Author:">Jonathan Lennox &lt;jonathan.lennox@8x8.com&gt <t>IANA has registered the media type registration "video/vp9"
;</t> as specified in <xref target="mediaTypeRegistration" format="default"/>.
The media type has also been added to the
"RTP Payload Format Media Types" <eref
target="https://www.iana.org/assignments/rtp-parameters"
brackets="angle"/> subregistry of the "Real-Time Transport Protocol (RTP)
Paramaeters" registry.</t>
<t hangText="Change controller:"><vspace blankLines="0"/> IETF </section>
AVTCore Working Group delegated from the IESG.</t>
</list></t>
</section>
<section anchor="securityConsiderations" title="Security Considerations" </middle>
> <back>
<t>RTP packets using the payload format defined in this specification <references>
are subject to the security considerations discussed in the RTP <name>References</name>
specification <xref target="RFC3550"/>, and in any applicable RTP <references>
profile such <name>Normative References</name>
as <xref target='RFC3551'>RTP/AVP</xref>, <xref target='RFC4585'>RTP/AVPF<
/xref>,
<xref target='RFC3711'>RTP/SAVP</xref>,
or <xref target='RFC5124'>RTP/SAVPF</xref>.
However, as <xref target='RFC7202'>"Securing the RTP Protocol
Framework: Why RTP Does Not Mandate a Single Media
Security Solution"</xref> discusses, it is not an RTP payload format's res
ponsibility to
discuss or mandate what solutions are used to meet the
basic security goals like confidentiality, integrity and source
authenticity for RTP in general. This responsibility lays on
anyone using RTP in an application. They can find guidance on available
security mechanisms in <xref target='RFC7201'>Options for Securing
RTP Sessions</xref>. Applications SHOULD use one or more appropriate
strong security mechanisms. The rest of this security
consideration section discusses the security impacting properties of the
payload format itself.</t>
<t>Implementations of this RTP payload format need to take appropriate sec <reference anchor="VP9-BITSTREAM" target="https://storage.googleapis.com
urity /downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-dr
considerations into account. It is extremely important for the decoder to aft.pdf">
be <front>
robust against malicious or malformed payloads and ensure that they do not <title>VP9 Bitstream &amp; Decoding Process Specification</title>
cause the decoder <author initials="A" surname="Grange" fullname="Adrian Grange">
to overrun its allocated memory or otherwise mis-behave. An overrun in al <organization>Google</organization>
located memory could lead to </author>
arbitrary code execution by an attacker. The same applies to the encoder, <author initials="P" surname="de Rivaz" fullname="Peter de Rivaz">
even <organization>Argon Design</organization>
though problems in encoders are typically rarer.</t> </author>
<author initials="J" surname="Hunt" fullname="Jonathan Hunt">
<organization>Argon Design</organization>
</author>
<date month="March" day="31" year="2016"/>
<abstract>
<t>
This document defines the bitstream format and decoding
process for the
Google VP9 video codec.
</t>
</abstract>
</front>
<seriesInfo name="Version" value="0.6"/>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4585.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3550.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8866.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6838.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4855.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5104.xml"/>
<t>This RTP payload <!-- [I-D.ietf-avtext-lrr] companion document RFC 9627 -->
format and its media decoder do not exhibit any significant <reference anchor="RFC9627" target="https://www.rfc-editor.org/info/rfc9627">
non-uniformity in the receiver-side computational complexity for packet <front>
processing, and thus are unlikely to pose a denial-of-service threat due <title>The Layer Refresh Request (LRR) RTCP Feedback Message</title>
to the receipt of pathological data. Nor does the RTP payload format <author initials="J." surname="Lennox" fullname="Jonathan Lennox">
contain any active content.</t> <organization>Vidyo, Inc.</organization>
</section> </author>
<author initials="D." surname="Hong" fullname="Danny Hong">
<organization>Vidyo, Inc.</organization>
</author>
<author initials="J." surname="Uberti" fullname="Justin Uberti">
<organization>Google, Inc.</organization>
</author>
<author initials="S." surname="Holmer" fullname="Stefan Holmer">
<organization>Google, Inc.</organization>
</author>
<author initials="M." surname="Flodman" fullname="Magnus Flodman">
<organization>Google, Inc.</organization>
</author>
<date month="August" year="2024" />
</front>
<seriesInfo name="RFC" value="9627" />
<seriesInfo name="DOI" value="10.17487/RFC9627"/>
<section anchor="congestionControl" title="Congestion Control"> </reference>
<t>Congestion control for RTP SHALL be used in accordance with RFC 3550
<xref target="RFC3550"/>, and with any applicable RTP profile; e.g., RFC
3551 <xref target="RFC3551"/>. The congestion control mechanism can, in
a real-time encoding scenario, adapt the transmission rate by
instructing the encoder to encode at a certain target rate. Media aware
network elements MAY use the information in the VP9 payload descriptor
in <xref target="VP9payloadDescriptor"/> to identify non-reference
frames and discard them in order to reduce network congestion. Note that
discarding of non-reference frames cannot be done if the stream is
encrypted (because the non-reference marker is encrypted).</t>
</section>
<section anchor="IANAConsiderations" title="IANA Considerations"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>The IANA is requested to register the media type registration FC.3264.xml"/>
"video/vp9" as specified in <xref </references>
target="mediaTypeRegistration"/>. The media type is also <references>
requested to <name>Informative References</name>
be added to the IANA registry for "RTP Payload Format MIME types" <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&lt;http://www.iana.org/assignments/rtp-parameters&gt;.</t> FC.3551.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5124.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6386.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7201.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7202.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7667.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3711.xml"/>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t><contact fullname="Alex Eleftheriadis"/>, <contact fullname="Yuki
Ito"/>, <contact fullname="Won Kap Jang"/>, <contact fullname="Sergio
Garcia"/> <contact fullname="Murillo"/>, <contact fullname="Roi
Sasson"/>, <contact fullname="Timothy Terriberry"/>, <contact
fullname="Emircan Uysaler"/>, and <contact fullname="Thomas Volkert"/>
commented on the development of this document and provided helpful
feedback.</t>
</section> </section>
<section title="Acknowledgments"> <!-- [rfced] Terminology and abbreviations: We had the following
<t>Alex Eleftheriadis, Yuki Ito, Won Kap Jang, Sergio Garcia questions related to terminology or abbreviation use throughout
Murillo, Roi Sasson, Timothy Terriberry, Emircan Uysaler, and the document.
Thomas Volkert commented on the development of this document and
provided helpful comments and feedback.</t>
</section>
</middle> a) The following terms had different forms throughout this
document. Please let us know if/how these may be made uniform.
<back> reference indices vs. Reference Indices
<references title='Normative References'>
<reference anchor='VP9-BITSTREAM' target='https://storage.googleapis.co b) We have updated these terms to be the form on the right to match
m/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-d use in the companion documents and/or be consistent within this
raft.pdf'> document.
<front>
<title>VP9 Bitstream &amp; Decoding Process Specification</titl
e>
<author initials='A' surname='Grange' fullname='Adrian Grange'> key frame vs. keyframe
<organization>Google</organization> "max-fs" vs. max-fs
</author> "max-fr" vs. max-fr
<author initials='P' surname='de Rivaz' fullname='Peter de Riva "profile-id" vs. profile-id
z'>
<organization>Argon Design</organization>
</author>
<author initials='J' surname='Hunt' fullname='Jonathan Hunt'>
<organization>Argon Design</organization>
</author>
<date month='March' day='31' year='2016' />
<abstract>
<t>
This document defines the bitstream format and decoding
process for the
Google VP9 video codec.
</t>
</abstract>
</front> c) How may we expand "SRGB"? Segment Routing Global Block? If so,
<seriesInfo name='Version' value='0.6' /> would you like to add as a note to the table? Or is this something
</reference> that could be housed in the Terminology section?
&rfc2119; d) Is SID expanded to spatial-layer ID? It seems so here:
&rfc8174; Original:
...temporal-layer ID (TID) and spatial layer ID (SID)...
&rfc4585; If SID is spatial-layer ID (please also see our cluster-wide question
regarding this abbreviation as well as our related question about TID
before responding), please review the following text as it seems to
state the SID is equal to SID:
&rfc3550; Original:
Within a picture, a frame with spatial layer ID equal to SID...
&rfc8866; Note also that it may be helpful to the reader to use the abbreviation
SID instead of the expansion (as recommended at
https://www.rfc-editor.org/styleguide/part2/). Please let us know any
objections to using this approach (once the expansion of SID is
determined).
&rfc6838; e) We note that TL0PICIDX is expanded in RFC-to-be 9626 as "Temporal
Layer 0 Picture Index". Please let us know if/how we may update the
following to make this document consistent within the cluster.
&rfc4855; Original:
TL0PICIDX: 8 bits temporal-layer zero index.
&rfc5104; and
&lrr; ...is used to represent temporal layer 0 index (TL0PICIDX)...
&rfc3264; Further, may we update to either "8-bit" or rephrase to put this
information in parentheses (as was done in RFC 9626)?
</references> f) Is N_S an abbreviation for "Number of Spatial layers"? Might the
explanation in Section 4.2.1 be made clearer?
<references title='Informative References'> Original:
N_S: N_S + 1 indicates the number of spatial layers present in the VP9
stream.
&rfc3551; Perhaps:
N_S: Number of Spatial layers. N_S + 1 indicates the number of
spatial layers present in the VP9 stream.
&rfc5124; g) Please note that we have expanded these abbreviations as follows.
Please let us know any objections.
&rfc6386; MCU - Multipoint Control Unit (per RFC 5104)
&rfc7201; -->;
&rfc7202; <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.
&rfc7667; We see the use of "native" but note that it is a quote from RFC 4585.
&rfc3711; In addition, please consider whether "tradition" and "traditionally"
should be updated for clarity. While the NIST website
<https://www.nist.gov/nist-research-library/nist-technical-series-publications-a
uthor-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.
-->
</references>
</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. 204 change blocks. 
930 lines changed or deleted 1255 lines changed or added

This html diff was produced by rfcdiff 1.48.