rfc9627xml2.original.xml   rfc9627.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" numbe
<!ENTITY rfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen r="9627" docName="draft-ietf-avtext-lrr-07" ipr="trust200902" obsoletes="" conse
ce.RFC.2119.xml"> nsus="true" updates="" submissionType="IETF" xml:lang="en" symRefs="true" sortRe
<!ENTITY rfc3550 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen fs="true" tocInclude="true" prepTime="2025-03-27T17:04:18" indexInclude="true" s
ce.RFC.3550.xml"> cripts="Common,Latin" tocDepth="3">
<!ENTITY rfc4585 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <link href="https://datatracker.ietf.org/doc/draft-ietf-avtext-lrr-07" rel="pr
ce.RFC.4585.xml"> ev"/>
<!ENTITY rfc5104 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <link href="https://dx.doi.org/10.17487/rfc9627" rel="alternate"/>
ce.RFC.5104.xml"> <link href="urn:issn:2070-1721" rel="alternate"/>
<!ENTITY rfc5234 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5234.xml">
<!ENTITY rfc6190 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6190.xml">
<!ENTITY rfc7656 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7656.xml">
<!ENTITY rfc7741 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7741.xml">
<!ENTITY rfc7798 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7798.xml">
<!ENTITY rfc8082 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8082.xml">
<!ENTITY vp9rtp SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/referen
ce.I-D.ietf-payload-vp9.xml">
<!ENTITY framemarking SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/r
eference.I-D.ietf-avtext-framemarking.xml">
]>
<rfc category="std" docName="draft-ietf-avtext-lrr-07" ipr="trust200902">
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<!-- alphabetize the references -->
<?rfc comments="no"?>
<!-- show comments -->
<?rfc inline="yes" ?>
<!-- comments are inline -->
<?rfc toc="yes" ?>
<!-- generate table of contents -->
<front> <front>
<title abbrev="Layer Refresh Request RTCP Feedback">The Layer Refresh Reques <title abbrev="LRR RTCP Feedback">The Layer Refresh Request (LRR) RTCP Feedb
t (LRR) RTCP Feedback Message</title> ack Message</title>
<seriesInfo name="RFC" value="9627" stream="IETF"/>
<author fullname="Jonathan Lennox" initials="J." surname="Lennox"> <author fullname="Jonathan Lennox" initials="J." surname="Lennox">
<organization abbrev="Vidyo">Vidyo, Inc.</organization> <organization abbrev="8x8 / Jitsi" showOnFrontPage="true">8x8, Inc. / Jits
i</organization>
<address> <address>
<postal> <postal>
<street>433 Hackensack Avenue</street> <city>Jersey City</city>
<street>Seventh Floor</street>
<city>Hackensack</city>
<region>NJ</region> <region>NJ</region>
<code>07302</code>
<code>07601</code> <country>United States of America</country>
<country>US</country>
</postal> </postal>
<email>jonathan.lennox@8x8.com</email>
<email>jonathan@vidyo.com</email>
</address> </address>
</author> </author>
<author fullname="Danny Hong" initials="D." surname="Hong">
<author fullname="Danny Hong" initials="D." surname="Hong"> <organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organiz
<organization abbrev="Vidyo">Vidyo, Inc.</organization> ation>
<address> <address>
<postal> <postal>
<street>433 Hackensack Avenue</street> <street>315 Hudson St.</street>
<city>New York</city>
<street>Seventh Floor</street> <region>NY</region>
<code>10013</code>
<city>Hackensack</city> <country>United States of America</country>
<region>NJ</region>
<code>07601</code>
<country>US</country>
</postal> </postal>
<email>dannyhong@google.com</email>
<email>danny@vidyo.com</email>
</address> </address>
</author> </author>
<author fullname="Justin Uberti" initials="J." surname="Uberti"> <author fullname="Justin Uberti" initials="J." surname="Uberti">
<organization abbrev="Google">Google, Inc.</organization> <organization showOnFrontPage="true">OpenAI</organization>
<address> <address>
<postal> <postal>
<street>747 6th Street South</street> <street>1455 3rd St</street>
<city>San Francisco</city>
<city>Kirkland</city> <region>CA</region>
<code>94158</code>
<region>WA</region> <country>United States of America</country>
<code>98033</code>
<country>USA</country>
</postal> </postal>
<email>justin@uberti.name</email> <email>justin@uberti.name</email>
</address> </address>
</author> </author>
<author fullname="Stefan Holmer" initials="S." surname="Holmer"> <author fullname="Stefan Holmer" initials="S." surname="Holmer">
<organization abbrev="Google">Google, Inc.</organization> <organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organiz
<address> ation>
<address>
<postal> <postal>
<street>Kungsbron 2</street> <street>Kungsbron 2</street>
<code>111 22</code> <code>111 22</code>
<city>Stockholm</city> <city>Stockholm</city>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>holmer@google.com</email> <email>holmer@google.com</email>
</address> </address>
</author> </author>
<author fullname="Magnus Flodman" initials="M." surname="Flodman"> <author fullname="Magnus Flodman" initials="M." surname="Flodman">
<organization abbrev="Google">Google, Inc.</organization> <organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organiz ation>
<address> <address>
<postal> <postal>
<street>Kungsbron 2</street> <street>Kungsbron 2</street>
<code>111 22</code> <code>111 22</code>
<city>Stockholm</city> <city>Stockholm</city>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>mflodman@google.com</email> <email>mflodman@google.com</email>
</address> </address>
</author> </author>
<date month="03" year="2025"/>
<date/>
<area>RAI</area> <area>RAI</area>
<workgroup>Payload Working Group</workgroup> <workgroup>Payload Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>RTP</keyword> <keyword>RTP</keyword>
<abstract pn="section-abstract">
<abstract> <t indent="0" pn="section-abstract-1">This memo describes the RTCP Payload
<t>This memo describes the RTCP Payload-Specific Feedback Message -Specific Feedback Message
"Layer Refresh Request" (LRR), which can be used to request a Layer Refresh Request (LRR), which can be used to request a
state refresh of one or more substreams of a layered media state refresh of one or more substreams of a layered media
stream. It also defines its use with several RTP payloads for stream. This document also defines its use with several RTP payl oads for
scalable media formats.</t> scalable media formats.</t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc9627" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-conventions-an
d-terminology">Conventions and Terminology</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><
xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-te
rminology">Terminology</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-layer-refresh-request">Layer Refre
sh Request</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
"3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-message-format">Messag
e Format</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-semantics">Semantics</
xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-usage-with-specific-codecs">Usage
with Specific Codecs</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-h264-svc">H.264 SVC</x
ref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-vp8">VP8</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-h265">H.265</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-usage-with-different-scalab">Usage
with Different Scalability Transmission Mechanisms</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-sdp-definitions">SDP Definitions</
xref></t>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.9.2">
<li pn="section-toc.1-1.9.2.1">
<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
"9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2">
<t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent=
"9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-informative-references
">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn
<t>This memo describes an <xref target="RFC3550">RTCP</xref> <xref target= ="section-1">
"RFC4585">Payload-Specific Feedback Message</xref> <name slugifiedName="name-introduction">Introduction</name>
"Layer Refresh Request" (LRR). It is designed to allow a <t indent="0" pn="section-1-1">This memo describes an <xref target="RFC355
0" format="default" sectionFormat="of" derivedContent="RFC3550">RTCP</xref> <xre
f target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585">
Payload-Specific Feedback Message</xref>
"Layer Refresh Request" (LRR), which is designed to allow a
receiver of a layered media stream to request that one or more receiver of a layered media stream to request that one or more
of its substreams be refreshed, such that it can then be of its substreams be refreshed. The stream can then be
decoded by an endpoint which previously was not receiving those decoded by an endpoint that previously was not receiving those
layers, without requiring that the layers, without requiring that the
entire stream be refreshed (as it would be if the receiver entire stream be refreshed (as it would be if the receiver
sent a <xref target='RFC5104'>Full Intra Request (FIR); </xref> sent a <xref target="RFC5104" format="default" sectionFormat="of"
see also <xref target='RFC8082' />).</t> derivedContent="RFC5104">Full Intra Request (FIR) </xref>;
see also <xref target="RFC8082" format="default" sectionFormat="o
<t>The feedback message is applicable both to temporally f" derivedContent="RFC8082"/>).</t>
and spatially scaled streams, and to both single-stream and <t indent="0" pn="section-1-2">The feedback message is applicable to both
temporally
and spatially scaled streams and to both single-stream and
multi-stream scalability modes.</t> multi-stream scalability modes.</t>
</section> </section>
<section anchor="conventions" numbered="true" toc="include" removeInRFC="fal
<section anchor="conventions" se" pn="section-2">
title="Conventions, Definitions and Acronyms"> <name slugifiedName="name-conventions-and-terminology">Conventions and Ter
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", minology</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this <t indent="0" pn="section-2-1">
document are to be interpreted as described in <xref The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
target="RFC2119"/>.</t> IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
<section anchor="terminology" OT RECOMMENDED</bcp14>",
title="Terminology"> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<t>A "Layer Refresh Point" is a point in a scalable stream after be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section anchor="terminology" numbered="true" toc="include" removeInRFC="f
alse" pn="section-2.1">
<name slugifiedName="name-terminology">Terminology</name>
<t indent="0" pn="section-2.1-1">A "layer refresh point" is a point in a
scalable stream after
which a decoder, which previously had been able to decode only some which a decoder, which previously had been able to decode only some
(possibly none) of the available layers of stream, is able to (possibly none) of the available layers of stream, is able to
decode a greater number of the layers.</t> decode a greater number of the layers.</t>
<t indent="0" pn="section-2.1-2">For spatial (or quality) layers, in nor
<t>For spatial (or quality) layers, in normal encoding, mal encoding,
a subpicture can depend both on earlier pictures of that a subpicture can depend both on earlier pictures of that
spatial layer and also on lower-layer pictures of the current pic ture. spatial layer and also on lower-layer pictures of the current pic ture.
A layer refresh, however, typically However, a layer refresh typically
requires that a spatial layer picture be encoded in a way that requires that a spatial-layer picture be encoded in a way that
references only the lower-layer subpictures of the current picture, references only the lower-layer subpictures of the current picture,
not any earlier pictures of that spatial layer. Additionally, not any earlier pictures of that spatial layer. Additionally,
the encoder must promise that no earlier pictures of that the encoder must promise that no earlier pictures of that
spatial layer will be used as reference in the future.</t> spatial layer will be used as reference in the future.</t>
<t indent="0" pn="section-2.1-3">However, even in a layer refresh, layer
<t>However, even in a layer refresh, layers other than the ones s other than the ones
being refreshed may still maintain dependency on earlier being refreshed may still maintain dependency on earlier
content of the stream. This is the difference between a layer content of the stream. This is the difference between a layer
refresh and a <xref target='RFC5104'>Full Intra refresh and a <xref target="RFC5104" format="default" sectionFormat="of
Request</xref>. This minimizes the coding overhead of refresh " derivedContent="RFC5104">FIR</xref>. This minimizes the coding overhead of re
fresh
to only those parts of the stream that actually need to be to only those parts of the stream that actually need to be
refreshed at any given time.</t> refreshed at any given time.</t>
<t keepWithNext="true" indent="0" pn="section-2.1-4">The spatial-layer r
<figure anchor="figureSpatialRefreshEnhanced"> efresh of an
<preamble>An illustration of spatial layer refresh of an enhancement layer is shown below. The "&lt;--" indicates a coding
enhancement layer is shown below. &lt;-- indicates a coding dependency.</t>
dependency.</preamble> <figure anchor="figureSpatialRefreshEnhanced" align="left" suppress-titl
<artwork><![CDATA[ e="false" pn="figure-1">
... <-- S1 <-- S1 S1 <-- S1 <-- ... <name slugifiedName="name-refresh-of-a-spatial-enhanc">Refresh of a Sp
atial Enhancement Layer</name>
<artwork name="" type="" align="left" alt="" pn="section-2.1-5.1">
... &lt;-- S1 &lt;-- S1 S1 &lt;-- S1 &lt;-- ...
| | | | | | | |
\/ \/ \/ \/ \/ \/ \/ \/
... <-- S0 <-- S0 <-- S0 <-- S0 <-- ... ... &lt;-- S0 &lt;-- S0 &lt;-- S0 &lt;-- S0 &lt;-- ...
1 2 3 4
]]></artwork>
</figure>
<t>In <xref target='figureSpatialRefreshEnhanced'/>, frame 3 is a layer re
fresh
point for spatial layer S1; a decoder which had previousl
y
only been decoding spatial layer S0 would be able to
decode layer S1 starting at frame 3.</t>
<figure anchor="figureSpatialRefreshBase"> 1 2 3 4</artwork>
<preamble>An illustration of spatial layer refresh of a base layer is sh </figure>
own <t indent="0" pn="section-2.1-6">In <xref target="figureSpatialRefreshEn
below. &lt;-- indicates a coding dependency.</preamble> hanced" format="default" sectionFormat="of" derivedContent="Figure 1"/>,
<artwork><![CDATA[ frame 3 is a layer refresh point for spatial layer S1; a decoder that
... <-- S1 <-- S1 <-- S1 <-- S1 <-- ... had previously only been decoding spatial layer S0 would be able to
decode layer S1 starting at frame 3.</t>
<t keepWithNext="true" indent="0" pn="section-2.1-7">The spatial-layer r
efresh of a base layer is shown
below. The "&lt;--" indicates a coding dependency.</t>
<figure anchor="figureSpatialRefreshBase" align="left" suppress-title="f
alse" pn="figure-2">
<name slugifiedName="name-refresh-of-a-spatial-base-l">Refresh of a Sp
atial Base Layer</name>
<artwork name="" type="" align="left" alt="" pn="section-2.1-8.1">
... &lt;-- S1 &lt;-- S1 &lt;-- S1 &lt;-- S1 &lt;-- ...
| | | | | | | |
\/ \/ \/ \/ \/ \/ \/ \/
... <-- S0 <-- S0 S0 <-- S0 <-- ... ... &lt;-- S0 &lt;-- S0 S0 &lt;-- S0 &lt;-- ...
1 2 3 4
]]></artwork>
</figure>
<t>In <xref target="figureSpatialRefreshBase"/>, frame 3 is a layer refres
h
point for spatial layer S0; a decoder which had previously
not been decoding the stream at all could decode layer S0
starting at frame 3.</t>
<t>For temporal layers, while normal encoding allows frames to
depend on earlier frames of the same temporal layer,
layer refresh requires that the layer be
"temporally nested", i.e. use as reference only
earlier frames of a lower temporal layer, not any earlier frames of thi
s
temporal layer, and also promise that no future frames
of this temporal layer will reference frames of this temporal
layer before the refresh point. In many cases, the temporal
structure of the stream will mean that all frames are
temporally nested, in which case decoders will have no need to
send LRR messages for the stream.</t>
<figure anchor="figureTemporalRefresh"> 1 2 3 4</artwork>
<preamble>An illustration of temporal layer refresh is shown </figure>
below. &lt;-- indicates a coding dependency.</preamble> <t indent="0" pn="section-2.1-9">In <xref target="figureSpatialRefreshBa
<artwork><![CDATA[ se" format="default" sectionFormat="of" derivedContent="Figure 2"/>,
... <----- T1 <------ T1 T1 <------ ... frame 3 is a layer refresh point for spatial layer S0; a decoder that
had previously not been decoding the stream at all could decode layer
S0 starting at frame 3.</t>
<t indent="0" pn="section-2.1-10">For temporal layers, while normal enco
ding allows frames to depend
on earlier frames of the same temporal layer, layer refresh requires
that the layer be "temporally nested", i.e., use as reference only
earlier frames of a lower temporal layer, not any earlier frames of
this temporal layer and promise that no future frames of this
temporal layer will reference frames of this temporal layer before the
refresh point. In many cases, the temporal structure of the stream
will mean that all frames are temporally nested; in this case,
decoders will have no need to send LRR messages for the stream.</t>
<t keepWithNext="true" indent="0" pn="section-2.1-11">The temporal layer
refresh is shown
below. The "&lt;--" indicates a coding dependency.</t>
<figure anchor="figureTemporalRefresh" align="left" suppress-title="fals
e" pn="figure-3">
<name slugifiedName="name-refresh-of-a-temporal-layer">Refresh of a Te
mporal Layer</name>
<artwork name="" type="" align="left" alt="" pn="section-2.1-12.1">
... &lt;----- T1 &lt;------ T1 T1 &lt;------ ...
/ / / / / /
|_ |_ |_ |_ |_ |_
... <-- T0 <------ T0 <------ T0 <------ T0 <--- ... ... &lt;-- T0 &lt;------ T0 &lt;------ T0 &lt;------ T0 &lt;--- ...
1 2 3 4 5 6 7
]]></artwork>
</figure>
<t>In <xref target="figureTemporalRefresh"/>, frame 6 is a layer refresh
point for temporal layer T1; a decoder which had previously
only been decoding temporal layer T0 would be able to
decode layer T1 starting at frame 6.</t>
<figure anchor="figureTemporalNesting"> 1 2 3 4 5 6 7</artwork>
<preamble>An illustration of an inherently temporally nested </figure>
stream is shown below. &lt;-- indicates a coding dependency.</preamble> <t indent="0" pn="section-2.1-13">In <xref target="figureTemporalRefresh
<artwork><![CDATA[ " format="default" sectionFormat="of" derivedContent="Figure 3"/>, frame 6
is a layer refresh point for temporal layer T1; a decoder that had
previously only been decoding temporal layer T0 would be able to
decode layer T1 starting at frame 6.</t>
<t keepWithNext="true" indent="0" pn="section-2.1-14">An inherently temp
orally nested
stream is shown below. The "&lt;--" indicates a coding dependency.</t>
<figure anchor="figureTemporalNesting" align="left" suppress-title="fals
e" pn="figure-4">
<name slugifiedName="name-an-inherently-temporally-ne">An Inherently T
emporally Nested Stream</name>
<artwork name="" type="" align="left" alt="" pn="section-2.1-15.1">
T1 T1 T1 T1 T1 T1
/ / / / / /
|_ |_ |_ |_ |_ |_
... <-- T0 <------ T0 <------ T0 <------ T0 <--- ... ... &lt;-- T0 &lt;------ T0 &lt;------ T0 &lt;------ T0 &lt;--- ...
1 2 3 4 5 6 7
]]></artwork>
</figure>
<t>In <xref target="figureTemporalNesting"/>, the stream is temporally 1 2 3 4 5 6 7</artwork>
</figure>
<t indent="0" pn="section-2.1-16">In <xref target="figureTemporalNesting
" format="default" sectionFormat="of" derivedContent="Figure 4"/>, the stream is
temporally
nested in its ordinary structure; a decoder receiving layer nested in its ordinary structure; a decoder receiving layer
T0 can begin decoding layer T1 at any point.</t> T0 can begin decoding layer T1 at any point.</t>
<t indent="0" pn="section-2.1-17">A "layer index" is a numeric label for
<t>A "Layer Index" is a numeric label for a specific spatial and a specific spatial and
temporal layer of a scalable stream. It temporal layer of a scalable stream. It
consists of the pair of a "temporal ID" identifying the temporal consists of both a "temporal-layer ID" identifying the temporal
layer, and a "layer ID" identifying the spatial or quality layer and a "layer ID" identifying the spatial or quality
layer. The details of how layers of a scalable stream are labeled are layer. The details of how layers of a scalable stream are labeled are
codec-specific. Details for several codecs are defined in codec specific. Details for several codecs are defined in
<xref target="codec-details"/>.</t> <xref target="codec-details" format="default" sectionFormat="of" derive
dContent="Section 4"/>.</t>
</section> </section>
</section> </section>
<section anchor="layerRefreshRequest" numbered="true" toc="include" removeIn
<section anchor="layerRefreshRequest" title="Layer Refresh Request"> RFC="false" pn="section-3">
<t>A layer refresh frame can be requested by sending a Layer Refresh Re <name slugifiedName="name-layer-refresh-request">Layer Refresh Request</na
quest (LRR), me>
which is an <xref target="RFC3550">RTP Control Protocol (RTCP)</xref> <t indent="0" pn="section-3-1">A layer refresh frame can be requested by s
<xref target="RFC4585">payload-specific feedback message</xref> asking ending a Layer Refresh
the encoder to encode a frame Request (LRR), which is an <xref target="RFC3550" format="default" section
which makes it possible to upgrade to a higher layer. The LRR Format="of" derivedContent="RFC3550">RTCP</xref> <xref target="RFC4585" format="
contains one or two tuples, indicating the temporal and spatial layer t default" sectionFormat="of" derivedContent="RFC4585">payload-specific feedback m
he decoder essage</xref> asking the
wants to upgrade to, and (optionally) the currently highest encoder to encode a frame that makes it possible to upgrade to a higher
temporal and spatial layer. The LRR contains one or two tuples, indicating the temporal and
layer the decoder can decode.</t> spatial layer the decoder wants to upgrade to and (optionally) the
currently highest temporal and spatial layer the decoder can decode.</t>
<t>The specific format of the tuples, and the mechanism by which <t indent="0" pn="section-3-2">The specific format of the tuples, and the
mechanism by which
a receiver recognizes a refresh frame, is a receiver recognizes a refresh frame, is
codec-dependent. Usage for several codecs is discussed in codec dependent. Usage for several codecs is discussed in
<xref target="codec-details"/>.</t> <xref target="codec-details" format="default" sectionFormat="of" derive
dContent="Section 4"/>.</t>
<t>LRR follows the model of the <xref target="RFC5104">Full <t indent="0" pn="section-3-3">The design of LRR follows the FIR model (<x
Intra Request (FIR)</xref> (Section 3.5.1) for its ref target="RFC5104" sectionFormat="of" section="3.5.1" format="default" derived
retransmission, reliability, and use in multipoint conferences.</t> Link="https://rfc-editor.org/rfc/rfc5104#section-3.5.1" derivedContent="RFC5104"
/>) for its retransmission,
<t>The LRR message is identified by RTCP packet type value reliability, and use in multipoint conferences.</t>
PT=PSFB and FMT=TBD. The FCI field MUST contain one or more LRR entrie <t indent="0" pn="section-3-4">The LRR message is identified by RTCP packe
s. Each entry t type value PT=PSFB and
applies to a different media sender, identified by its SSRC.</t> FMT=10. The Feedback Control Information (FCI) field <bcp14>MUST</bcp14>
contain one or more LRR
<t>[NOTE TO RFC Editor: Please replace "TBD" with the IANA-assigned pay entries. Each entry applies to a different media sender, identified by
load-specific feedback its Synchronization Source (SSRC).</t>
number.]</t> <section anchor="MessageFormat" numbered="true" toc="include" removeInRFC=
"false" pn="section-3.1">
<section anchor="MessageFormat" title="Message Format"> <name slugifiedName="name-message-format">Message Format</name>
<t indent="0" pn="section-3.1-1">The FCI for the Layer Refresh Request
<t>The Feedback Control Information (FCI) for the Layer Refresh R
equest
consists of one or more FCI entries, the content of which is consists of one or more FCI entries, the content of which is
depicted in <xref target="figureFciFormat"/>. The length of depicted in <xref target="figureFciFormat" format="default" sectionFormat="of
the LRR feedback message MUST be set to " derivedContent="Figure 5"/>. The length of
the LRR feedback message <bcp14>MUST</bcp14> be set to
2+3*N 32-bit words, where N is the number of FCI entries.</t> 2+3*N 32-bit words, where N is the number of FCI entries.</t>
<figure anchor="figureFciFormat" align="left" suppress-title="false" pn=
<figure anchor="figureFciFormat"> "figure-5">
<artwork><![CDATA[ <name slugifiedName="name-layer-refresh-request-fci-f">Layer Refresh R
equest FCI Format</name>
<artwork name="" type="" align="left" alt="" pn="section-3.1-2.1">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC | | SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. |C| Payload Type| Reserved | | Seq nr. |C| Payload Type| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | TTID| TLID | RES | CTID| CLID | | RES | TTID| TLID | RES | CTID| CLID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </artwork>
</figure> </figure>
<dl newline="true" spacing="normal" indent="3" pn="section-3.1-3">
<t> <dt pn="section-3.1-3.1">Synchronization Source (SSRC) (32 bits):</dt>
<list style="hanging"> <dd pn="section-3.1-3.2"> The SSRC value of the media sender that is
<t hangText="SSRC (32 bits)"> The SSRC value of the media sende requested to send a layer refresh point.</dd>
r that is <dt pn="section-3.1-3.3">Seq nr. (8 bits):</dt>
requested to send a layer refresh point.</t> <dd pn="section-3.1-3.4">The command sequence number. The sequence nu
mber space is
<t hangText="Seq nr. (8 bits)"> Command sequence number. The s unique for each pairing of the SSRC of command source and the SSRC
equence number of the command target. The sequence number <bcp14>SHALL</bcp14> be
space is unique for each pairing of the SSRC of command increased by 1 for each new command (modulo 256, so the value after
source and the SSRC of the command target. The sequence 255 is 0). A repetition <bcp14>SHALL NOT</bcp14> increase the
number SHALL be increased by 1 for each new sequence number. The initial value is arbitrary.</dd>
command (modulo 256, so the value after 255 is 0). <dt pn="section-3.1-3.5">C (1 bit):</dt>
A repetition SHALL NOT increase the sequence <dd pn="section-3.1-3.6">A flag bit indicating whether the Current Tem
number. The initial value is arbitrary.</t> poral-layer ID
(CTID) and Current Layer ID (CLID) fields are present in the FCI.
<t hangText="C (1 bit)">A flag bit indicating whether the If this bit is 0, the sender of the LRR message is requesting
"Current Temporal Layer ID (CTID)" and "Current Layer ID refresh of all layers up to and including the target layer.</dd>
(CLID)" fields are present in the FCI. If <dt pn="section-3.1-3.7">Payload Type (7 bits):</dt>
this bit is 0, the sender of the LRR message is <dd pn="section-3.1-3.8">The RTP payload type for which the LRR is bei
requesting refresh of all layers up to and including the ng requested. This
target layer.</t> gives the context in which the target layer index is to be
interpreted.</dd>
<t hangText="Payload Type (7 bits)">The RTP payload type for <dt pn="section-3.1-3.9">Reserved (RES) (three separate fields of 16 b
which the LRR is being requested. This gives the context in its / 5 bits / 5
which the target layer index is to be interpreted.</t> bits):</dt>
<dd pn="section-3.1-3.10"> All bits <bcp14>SHALL</bcp14> be set to zer
<t hangText="Reserved (RES) (three separate fields, 16 bits / 5 o
bits / 5 bits)"> All bits SHALL be set to 0 by the sender and <bcp14>SHALL</bcp14> be ignored on rece
by the sender and SHALL be ignored on reception.</t> ption.</dd>
<dt pn="section-3.1-3.11">Target Temporal-layer ID (TTID) (3 bits):</d
<t hangText="Target Temporal Layer ID (TTID) (3 bits)">The temp t>
oral ID <dd pn="section-3.1-3.12">The temporal-layer ID of the target layer fo
of the target layer for which the receiver wishes a refre r which the receiver
sh point.</t> wishes a refresh point.</dd>
<dt pn="section-3.1-3.13">Target Layer ID (TLID) (8 bits):</dt>
<t hangText="Target Layer ID (TLID) (8 bits)">The layer ID of t <dd pn="section-3.1-3.14">The layer ID of the target spatial or qualit
he target spatial or quality y layer for which
layer the receiver wishes a refresh point. Its format is dependent on the
for which the receiver wishes a refresh point. Its forma payload type field.</dd>
t <dt pn="section-3.1-3.15">Current Temporal-layer ID (CTID) (3 bits):</
is dependent on the payload type field.</t> dt>
<dd pn="section-3.1-3.16">If C is 1, the ID of the current temporal la
<t hangText="Current Temporal Layer ID (CTID) (3 bits)">If C is yer being decoded by
1, the receiver. This message is not requesting refresh of layers at
the ID of the current temporal layer being decoded by the or below this layer. If C is 0, this field <bcp14>SHALL</bcp14> be
receiver. set to zero by the sender and <bcp14>SHALL</bcp14> be ignored on
This message is not requesting refresh of layers at or be reception.</dd>
low this layer. <dt pn="section-3.1-3.17">Current Layer ID (CLID) (8 bits):</dt>
If C is 0, this field SHALL be set to 0 by the sender and <dd pn="section-3.1-3.18">If C is 1, the
SHALL be ignored on reception.</t>
<t hangText="Current Layer ID (CLID) (8 bits)">If C is 1, the
layer ID of the current spatial or quality layer being decoded by the receiver. This message layer ID of the current spatial or quality layer being decoded by the receiver. This message
is not requesting refresh of layers at or below this layer. is not requesting refresh of layers at or below this layer.
If C is 0, this field SHALL be set to 0 by the sender and If C is 0, this field <bcp14>SHALL</bcp14> be set to zero by th
SHALL be ignored on reception.</t> e sender and
</list> <bcp14>SHALL</bcp14> be ignored on reception.</dd>
</t> </dl>
<t indent="0" pn="section-3.1-4">When C is 1, TTID <bcp14>MUST NOT</bcp1
<t>When C is 1, TTID MUST NOT be less than CTID, and TLID 4> be less than CTID, and
MUST NOT be less than CLID; at least one of TTID or TLID MUST be greate TLID <bcp14>MUST NOT</bcp14> be less than CLID; at least one of either
r TTID or TLID <bcp14>MUST</bcp14> be greater than CTID or CLID,
than CTID or CLID respectively. That is to say, the target layer index respectively. That is to say, the target layer index &lt;TTID,
&lt;TTID, TLID&gt; <bcp14>MUST</bcp14> be a layer upgrade from the current layer
TLID&gt; MUST be a layer upgrade from the current layer index &lt;CTID, index &lt;CTID, CLID&gt;. A sender <bcp14>MAY</bcp14> request an
CLID&gt;. upgrade in both temporal and spatial or quality layers
A sender MAY request an upgrade in both temporal and simultaneously.</t>
spatial/quality layers simultaneously.</t> <t indent="0" pn="section-3.1-5">A receiver receiving an LRR feedback pa
cket that does not satisfy
<t>A receiver receiving an LRR feedback packet which does not satisfy t the requirements of the previous paragraph, i.e., one where the C bit
he is present but the TTID is less than the CTID or the TLID is less than t
requirements of the previous paragraph, i.e. one where the C he CLID,
bit is present but TTID is less than CTID or TLID is less <bcp14>MUST</bcp14> discard the request.</t>
than CLID, MUST discard the request.</t> <aside pn="section-3.1-6">
<t indent="0" pn="section-3.1-6.1">Note: The syntax of the TTID, TLID,
<t>Note: the syntax of the TTID, TLID, CTID, and CLID fields CTID, and CLID fields match, by
match, by design, the TID and LID fields in design, the TID and LID fields in <xref target="RFC9626" format="default
<xref target='I-D.ietf-avtext-framemarking' />.</t> " sectionFormat="of" derivedContent="RFC9626"/>.</t>
</aside>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3.2
<section title="Semantics"> ">
<name slugifiedName="name-semantics">Semantics</name>
<t>Within the common packet header for feedback messages (as defi <t indent="0" pn="section-3.2-1">Within the common packet header for fee
ned in dback messages (as defined
section 6.1 of <xref target='RFC4585' />), the "SSRC of packet sender" field in <xref target="RFC4585" sectionFormat="of" section="6.1" format="defau
indicates the source of the request, and the "SSRC of media source" lt" derivedLink="https://rfc-editor.org/rfc/rfc4585#section-6.1" derivedContent=
is not used and SHALL be set to 0. The SSRCs of the media senders to "RFC4585"/>), the
which the LRR command applies are in the corresponding FCI entries. "SSRC of packet sender" field indicates the source of the request, and
A LRR message MAY contain requests to multiple media senders, using the "SSRC of media source" is not used and <bcp14>SHALL</bcp14> be set
one FCI entry per target media sender.</t> to zero. The SSRCs of the media senders to which the LRR command applie
s
<t>Upon reception of LRR, the encoder MUST send a decoder refresh point are in the corresponding FCI entries. An LRR message
(see <xref target='terminology' />) as soon as possible.</t> <bcp14>MAY</bcp14> contain requests to multiple media senders, using
one FCI entry per target media sender.</t>
<t>The sender MUST respect bandwidth limits provided by the <t indent="0" pn="section-3.2-2">Upon reception of an LRR, the encoder <
application of congestion control, as described in Section 5 of bcp14>MUST</bcp14> send a decoder refresh point
<xref target='RFC5104' />. As layer refresh points will often be (see <xref target="terminology" format="default" sectionFormat="of" derivedCo
larger than non-refreshing frames, this may restrict a sender's ntent="Section 2.1"/>) as soon as possible.</t>
ability to send a layer refresh point quickly.</t> <t indent="0" pn="section-3.2-3">The sender <bcp14>MUST</bcp14> respect
bandwidth limits provided by
<t>LRR MUST NOT be sent as a reaction to picture losses due to the application of congestion control, as described in <xref target="RFC
packet loss or corruption -- it is 5104" sectionFormat="of" section="5" format="default" derivedLink="https://rfc-e
RECOMMENDED to use <xref target="RFC4585">PLI</xref> instead. ditor.org/rfc/rfc5104#section-5" derivedContent="RFC5104"/>. As layer refresh
LRR SHOULD be used only in situations where there is an explicit change points will often be larger than non-refreshing frames, this may
in decoders' behavior, for restrict a sender's ability to send a layer refresh point quickly.</t>
example when a receiver will start decoding a layer which it <t indent="0" pn="section-3.2-4">An LRR <bcp14>MUST NOT</bcp14> be sent
previously had been discarding.</t> as a reaction to picture
losses due to packet loss or corruption; it is
</section> <bcp14>RECOMMENDED</bcp14> to use <xref target="RFC4585" format="default
</section> " sectionFormat="of" derivedContent="RFC4585">a PLI (Picture Loss Indication)</x
ref> instead. An LRR
<section anchor="codec-details" title="Usage with specific codecs"> <bcp14>SHOULD</bcp14> be used only in situations where there is an
explicit change in a decoder's behavior: for example, when a receiver
<t>In order for LRR to be used with a scalable codec, the format will start decoding a layer that it previously had been
of the temporal and layer ID fields (for both the target and discarding.</t>
current layer indices) needs to be </section>
specified for that codec's RTP packetization. New RTP </section>
packetization specifications for scalable codecs SHOULD define <section anchor="codec-details" numbered="true" toc="include" removeInRFC="f
how this is done. (The <xref target='I-D.ietf-payload-vp9'>VP9 alse" pn="section-4">
payload</xref>, for instance, has done so.) If the payload also <name slugifiedName="name-usage-with-specific-codecs">Usage with Specific
specifies how it is used with Codecs</name>
<xref target='I-D.ietf-avtext-framemarking'>the Frame Marking <t indent="0" pn="section-4-1">In order for an LRR to be used with a scala
RTP Header Extension</xref>, the syntax MUST be defined ble codec, the format of
in the same manner as the TID and LID fields in that header.</t> the temporal and layer ID fields (for both the target and current layer
indices) needs to be specified for that codec's RTP packetization. New
<section title="H264 SVC"> RTP packetization specifications for scalable codecs
<bcp14>SHOULD</bcp14> define how this is done. (The <xref target="RFC9628"
<t><xref target="RFC6190">H.264 SVC</xref> defines temporal, format="default" sectionFormat="of" derivedContent="RFC9628">VP9 payload</xref>
, for instance, has
done so.) If the payload also specifies how it is used with the Video
Frame Marking RTP Header Extension described in <xref target="RFC9626" for
mat="default" sectionFormat="of" derivedContent="RFC9626"/>, the syntax <bcp14>M
UST</bcp14> be defined in the
same manner as the TID and LID fields in that header.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.1
">
<name slugifiedName="name-h264-svc">H.264 SVC</name>
<t indent="0" pn="section-4.1-1"><xref target="RFC6190" format="default"
sectionFormat="of" derivedContent="RFC6190">H.264 SVC</xref> defines temporal,
dependency (spatial), and quality scalability modes.</t> dependency (spatial), and quality scalability modes.</t>
<figure anchor="figureH264SvcIndexFormat" align="left" suppress-title="f
<figure anchor="figureH264SvcIndexFormat"> alse" pn="figure-6">
<artwork><![CDATA[ <name slugifiedName="name-h264-svc-layer-index-fields">H.264 SVC Layer
Index Fields Format</name>
<artwork name="" type="" align="left" alt="" pn="section-4.1-2.1">
+---------------+---------------+ +---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | TID |R| DID | QID | | RES | TID |R| DID | QID |
+---------------+---------------+ +---------------+---------------+
]]></artwork> </artwork>
</figure> </figure>
<t indent="0" pn="section-4.1-3"><xref target="figureH264SvcIndexFormat"
<t><xref target="figureH264SvcIndexFormat"/> shows the format format="default" sectionFormat="of" derivedContent="Figure 6"/> shows the forma
t
of the layer index fields for H.264 SVC streams. The "R" and "RE S" of the layer index fields for H.264 SVC streams. The "R" and "RE S"
fields MUST be set to 0 on transmission and ignored on fields <bcp14>MUST</bcp14> be set to zero on transmission and ign
reception. See <xref target='RFC6190'/> Section 1.1.3 for ored on
details on the DID, QID, and TID fields.</t> reception. See <xref target="RFC6190" sectionFormat="of" section
="1.1.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6190#sectio
<t>A dependency or quality layer refresh of a given layer in n-1.1.3" derivedContent="RFC6190"/> for
H.264 SVC can be identified by the "I" bit (idr_flag) in the details on the dependency_id (DID), quality_id (QID), and
extended NAL unit header, present in NAL unit types 14 (prefix temporal_id (TID) fields.</t>
NAL unit) and 20 (coded scalable slice). Layer refresh of the <t indent="0" pn="section-4.1-4">A dependency or quality layer refresh o
base layer can also be identified by its NAL unit type of f a given layer in H.264 SVC
its coded slices, which is "5" rather than "1". A dependency or can be identified by the I bit (idr_flag) in the extended Network
quality layer refresh is complete once this bit has been seen Abstraction Layer (NAL) unit header, present in NAL unit types 14
on all the appropriate layers (in decoding order) above the (prefix NAL unit) and 20 (coded scalable slice). Layer refresh of the
current layer index (if any, or beginning from the base layer base layer can also be identified by its NAL unit type of its coded
if not) through the target layer index.</t> slices, which is "5" rather than "1". A dependency or quality layer
refresh is complete once this bit has been seen on all the appropriate
<t>Note that as the "I" bit in a PACSI header is set if the layers (in decoding order) above the current layer index (if any, or
corresponding bit is set in any of the aggregated NAL units it beginning from the base layer if not) through the target layer
describes; thus, it is not sufficient to identify layer index.</t>
refresh when NAL units of multiple dependency or quality layers <t indent="0" pn="section-4.1-5">Note that as the I bit in a Payload Con
are aggregated.</t> tent Scalability
Information (PACSI) header is set if the corresponding bit is set in
<t>In H.264 SVC, temporal layer refresh information can be any of the aggregated NAL units it describes; thus, it is not
sufficient to identify layer refresh when NAL units of multiple
dependency or quality layers are aggregated.</t>
<t indent="0" pn="section-4.1-6">In H.264 SVC, temporal layer refresh in
formation can be
determined from various Supplemental Encoding Information determined from various Supplemental Encoding Information
(SEI) messages in the bitstream.</t> (SEI) messages in the bitstream.</t>
<t indent="0" pn="section-4.1-7">Whether an H.264 SVC stream is scalably
<t>Whether an H.264 SVC stream is scalably nested can be determin nested can be determined from
ed from
the Scalability Information SEI message's temporal_id_nesting the Scalability Information SEI message's temporal_id_nesting
flag. If this flag is set in a stream's currently applicable flag. If this flag is set in a stream's currently applicable
Scalability Information SEI, receivers SHOULD NOT send Scalability Information SEI, receivers <bcp14>SHOULD NOT</bcp14> send
temporal LRR messages for that stream, as every frame is temporal LRR messages for that stream, as every frame is
implicitly a temporal layer refresh point. (The Scalability implicitly a temporal layer refresh point. (The Scalability
Information SEI message may also be available in the signaling Information SEI message may also be available in the signaling
negotiation of H.264 SVC, as the sprop-scalability-info negotiation of H.264 SVC as the sprop-scalability-info
parameter.)</t> parameter.)</t>
<t indent="0" pn="section-4.1-8">If a stream's temporal_id_nesting flag
<t>If a stream's temporal_id_nesting flag is not set, the is not set, the Temporal
Temporal Level Switching Point SEI message identifies temporal Level Switching Point SEI message identifies temporal layer switching
layer switching points. A temporal layer refresh is satisfied points. A temporal layer refresh is satisfied when this SEI message
when this SEI message is present in a frame with the target is present in a frame with the target layer index, if the message's
layer index, if the message's delta_frame_num refers to a frame delta_frame_num refers to a frame with the requested current layer
with the requested current layer index. (Alternately, index. (Alternately, temporal layer refresh can also be satisfied by
temporal layer refresh can also be satisfied by a complete a complete state refresh, such as an Instantaneous Decoding Refresh
state refresh, such as an IDR.) Senders which support (IDR).) Senders that support receiving an LRR for streams that are not
receiving LRR for non-temporally-nested streams MUST insert temporally nested
Temporal Level Switching Point SEI messages as appropriate.</t> <bcp14>MUST</bcp14> insert Temporal Level Switching Point SEI
messages as appropriate.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.2
<section title="VP8"> ">
<name slugifiedName="name-vp8">VP8</name>
<t><xref target="RFC7741">The VP8 RTP payload <t indent="0" pn="section-4.2-1">The <xref target="RFC7741" format="defa
ult" sectionFormat="of" derivedContent="RFC7741">VP8 RTP payload
format</xref> defines temporal scalability modes. It does not format</xref> defines temporal scalability modes. It does not
support spatial scalability.</t> support spatial scalability.</t>
<figure anchor="figureVP8IndexFormat" align="left" suppress-title="false
<figure anchor="figureVP8IndexFormat"> " pn="figure-7">
<artwork><![CDATA[ <name slugifiedName="name-vp8-layer-index-field-forma">VP8 Layer Index
Field Format</name>
<artwork name="" type="" align="left" alt="" pn="section-4.2-2.1">
+---------------+---------------+ +---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | TID | RES | | RES | TID | RES |
+---------------+---------------+ +---------------+---------------+
]]></artwork> </artwork>
</figure> </figure>
<t indent="0" pn="section-4.2-3"><xref target="figureVP8IndexFormat" for
<t><xref target="figureVP8IndexFormat"/> shows the format mat="default" sectionFormat="of" derivedContent="Figure 7"/> shows the
of the layer index field for VP8 streams. The "RES" format of the layer index field for VP8 streams. The "RES" fields
fields MUST be set to 0 on transmission and be ignored on <bcp14>MUST</bcp14> be set to zero on transmission and be ignored on
reception. See <xref target='RFC7741'/> Section 4.2 for reception. See <xref target="RFC7741" sectionFormat="of" section="4.2"
details on the TID field.</t> format="default" derivedLink="https://rfc-editor.org/rfc/rfc7741#section-4.2" de
rivedContent="RFC7741"/> for details on the TID field.</t>
<t>A VP8 layer refresh point can be identified by the presence <t indent="0" pn="section-4.2-4">A VP8 layer refresh point can be identi
of the "Y" bit in the VP8 payload header. When this bit is fied by the presence of the
set, this and all subsequent frames depend only on the current Y bit (see <xref target="RFC7741" format="default" sectionFormat="of" de
base temporal layer. On receipt of an LRR for a VP8 stream, A rivedContent="RFC7741"/>) in the VP8 payload header. When this bit is set, this
sender which supports LRR MUST encode the stream so it can set th and all
e subsequent frames depend only on the current base temporal layer. On
Y bit in a packet whose temporal layer is at or below the target receipt of an LRR for a VP8 stream, a sender that supports LRRs
layer index.</t> <bcp14>MUST</bcp14> encode the stream so it can set the Y bit in a
packet whose temporal layer is at or below the target layer index.</t>
<t>Note that in VP8, not every layer switch point can be <t indent="0" pn="section-4.2-5">Note that in VP8, not every layer switc
identified by the Y bit, since the Y bit implies layer switch h point can be identified by
of all layers, not just the layer in which it is sent. Thus the Y bit since the Y bit implies layer switch of all layers, not
the use of LRR with VP8 can result in some inefficiency in just the layer in which it is sent. Thus, the use of an LRR with VP8 ca
transmision. However, this is not expected to be a major n
issue for temporal structures in normal use.</t> result in some inefficiency in transmission. However, this is not
expected to be a major issue for temporal structures in normal
</section> use.</t>
</section>
<section title="H265"> <section numbered="true" toc="include" removeInRFC="false" pn="section-4.3
">
<t>The initial version <name slugifiedName="name-h265">H.265</name>
of <xref target="RFC7798">the H.265 payload <t indent="0" pn="section-4.3-1">The initial version of the <xref target
format</xref> defines temporal scalability, with protocol ="RFC7798" format="default" sectionFormat="of" derivedContent="RFC7798">H.265 pa
elements reserved for spatial or other scalability modes yload format</xref> defines temporal
(which are expected to be defined in a future version of the scalability, with protocol elements reserved for spatial or other
specification).</t> scalability modes (which are expected to be defined in a future
version of the specification).</t>
<figure anchor="figureH265IndexFormat"> <figure anchor="figureH265IndexFormat" align="left" suppress-title="fals
<artwork><![CDATA[ e" pn="figure-8">
<name slugifiedName="name-h265-layer-index-fields-for">H.265 Layer Ind
ex Fields Format</name>
<artwork name="" type="" align="left" alt="" pn="section-4.3-2.1">
+---------------+---------------+ +---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | TID |RES| LayerId | | RES | TID |RES| layer ID |
+---------------+---------------+ +---------------+---------------+
]]></artwork> </artwork>
</figure> </figure>
<t indent="0" pn="section-4.3-3"><xref target="figureH265IndexFormat" fo
<t><xref target="figureH265IndexFormat"/> shows the format rmat="default" sectionFormat="of" derivedContent="Figure 8"/> shows the
of the layer index field for H.265 streams. The "RES" format of the layer index field for H.265 streams. The "RES" fields
fields MUST be set to 0 on transmission and ignored on <bcp14>MUST</bcp14> be set to zero on transmission and ignored on
reception. See <xref target='RFC7798'/> Section 1.1.4 for reception. See <xref target="RFC7798" sectionFormat="of" section="1.1.4
details on the LayerId and TID fields.</t> " format="default" derivedLink="https://rfc-editor.org/rfc/rfc7798#section-1.1.4
" derivedContent="RFC7798"/> for details on the layer ID and TID fields.</t>
<t>H.265 streams signal whether they are temporally nested, <t indent="0" pn="section-4.3-4">H.265 streams signal whether they are t
using the vps_temporal_id_nesting_flag in the Video Parameter emporally nested by using the
Set (VPS), and the sps_temporal_id_nesting_flag in the Sequence vps_temporal_id_nesting_flag in the Video Parameter Set (VPS) and the
Parameter Set (SPS). If this flag is set in a stream's currently sps_temporal_id_nesting_flag in the Sequence Parameter Set (SPS). If
applicable this flag is set in a stream's currently applicable VPS or SPS,
VPS or SPS, receivers SHOULD NOT send temporal LRR messages receivers <bcp14>SHOULD NOT</bcp14> send temporal LRR messages for
for that stream, as every frame is implicitly a temporal layer that stream, as every frame is implicitly a temporal layer refresh
refresh point.</t> point.</t>
<t indent="0" pn="section-4.3-5">If a stream's sps_temporal_id_nesting_f
<t>If a stream's sps_temporal_id_nesting_flag is not set, the lag is not set, the
NAL unit types 2 to 5 inclusively identify temporal NAL unit types 2 to 5 inclusively identify temporal
layer switching points. A layer refresh to any higher layer switching points. A layer refresh to any higher
target temporal layer is satisfied when a NAL unit type of 4 or 5 target temporal layer is satisfied when a NAL unit type of 4 or 5
with TID equal to 1 more than current TID is seen. Alternatively , with TID equal to 1 more than current TID is seen. Alternatively ,
layer refresh to a target temporal layer can be incrementally layer refresh to a target temporal layer can be incrementally
satisfied with NAL unit type of 2 or 3. In this case, given satisfied with a NAL unit type of 2 or 3. In this case, given
current TID = TO and target TID = TN, layer refresh to TN is sati sfied current TID = TO and target TID = TN, layer refresh to TN is sati sfied
when NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, when a NAL unit type of 2 or 3 is seen for TID = T1, then TID = T
all the way up to TID = TN. During this incremental process, lay 2,
er all the way up to TID = TN (note that
TN and TO refer to nonce variables in this instance). During this incremental p
rocess, layer
refresh to TN can be completely satisfied as soon as a NAL unit t ype refresh to TN can be completely satisfied as soon as a NAL unit t ype
of 2 or 3 is seen.</t> of 2 or 3 is seen.</t>
<t indent="0" pn="section-4.3-6">Of course, temporal layer refresh can a
<t>Of course, temporal layer refresh can also be satisfied whenev lso be satisfied whenever
er any Intra-Random Access Point (IRAP) NAL unit type (with values 1
any Intra Random Access Point (IRAP) NAL unit type (with values 1 6-23,
6-23,
inclusively) is seen. An IRAP picture is similar to an IDR pictu re in inclusively) is seen. An IRAP picture is similar to an IDR pictu re in
H.264 (NAL unit type of 5 in H.264) where decoding of the picture can start H.264 (NAL unit type of 5 in H.264) where decoding of the picture can start
without any older pictures.</t> without any older pictures.</t>
<t indent="0" pn="section-4.3-7">In the (future) H.265 payloads that sup
<t>In the (future) H.265 payloads that support spatial port spatial
scalability, a spatial layer refresh of a specific layer can scalability, a spatial-layer refresh of a specific layer can
be identified by NAL units with the requested layer ID and NAL be identified by NAL units with the requested layer ID and NAL
unit types between 16 and 21 inclusive. A dependency or unit types between 16 and 21, inclusive. A dependency or
quality layer refresh is complete once NAL units of this type hav e been seen quality layer refresh is complete once NAL units of this type hav e been seen
on all the appropriate layers (in decoding order) above the on all the appropriate layers (in decoding order) above the
current layer index (if any, or beginning from the base layer current layer index (if any, or beginning from the base layer
if not) through the target layer index.</t> if not) through the target layer index.</t>
</section> </section>
</section>
</section> <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
<name slugifiedName="name-usage-with-different-scalab">Usage with Differen
<section title="Usage with different scalability transmission mechanisms" t Scalability Transmission Mechanisms</name>
> <t indent="0" pn="section-5-1">Several different mechanisms are defined fo
r how scalable streams can
<t>Several different mechanisms are defined for how scalable be transmitted in RTP. <xref target="RFC7656" sectionFormat="of" section="
streams can be transmitted in RTP. 3.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7656#section-3.
The <xref target="RFC7656">RTP 7" derivedContent="RFC7656">"A Taxonomy of Semantics and Mechanisms for Real-Tim
Taxonomy</xref> Section 3.7 defines three mechanisms: Single RTP e Transport Protocol (RTP) Sources"</xref> defines three mechanisms: Single RTP
Stream on a Single Media Transport (SRST), Multiple RTP Streams stream on a Single media Transport (SRST), Multiple RTP streams on a
on a Single Media Transport (MRST), and Multiple RTP Streams on Single media Transport (MRST), and Multiple RTP streams on Multiple
Multiple Media Transports (MRMT).</t> media Transports (MRMT).</t>
<t indent="0" pn="section-5-2">The LRR message is applicable to all these
<t>The LRR message is applicable to all these mechanisms. For mechanisms. For MRST and
MRST and MRMT mechanisms, the "media source" field of the LRR MRMT mechanisms, the "media source" field of the LRR FCI is set to the
FCI is set to the SSRC of the RTP stream containing the layer SSRC of the RTP stream containing the layer indicated by the Current
indicated by the Current Layer Index (if "C" is 1), or the Layer Index (if "C" is 1) or the stream containing the base encoded
stream containing the base encoded stream (if "C" is 0). For stream (if "C" is 0). For MRMT, the LRR message is sent on the RTP
MRMT, it is sent on the RTP session on which this stream is session on which this stream is sent. On receipt, the sender
sent. On receipt, the sender MUST refresh all the layers <bcp14>MUST</bcp14> refresh all the layers requested in the stream,
requested in the stream, simultaneously in decode order.</t> simultaneously in decode order.</t>
</section>
</section> <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
<name slugifiedName="name-sdp-definitions">SDP Definitions</name>
<section title="SDP Definitions"> <t indent="0" pn="section-6-1"><xref target="RFC5104" sectionFormat="of" s
ection="7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5104#sect
<t>Section 7 of <xref target='RFC5104' /> defines SDP procedures ion-7" derivedContent="RFC5104"/> defines Session Description Protocol (SDP) pro
for indicating and negotiating support for codec control cedures
messages (CCM) in SDP. This document extends this with a new for indicating and negotiating support for Codec Control
codec control command, "lrr", which indicates support of the Messages (CCM) in SDP. This document extends this with a new
Layer Refresh Request (LRR).</t> codec control command, "lrr", which indicates support of the LRR.</t>
<t indent="0" pn="section-6-2"><xref target="lrr_grammar" format="default"
<t><xref target='lrr_grammar' /> gives a formal sectionFormat="of" derivedContent="Figure 9"/> gives a formal
<xref target='RFC5234'>Augmented Backus-Naur Form (ABNF)</xref> <xref target="RFC5234" format="default" sectionFormat="of" derivedConte
nt="RFC5234">Augmented Backus-Naur Form (ABNF)</xref>
showing this grammar extension, extending the grammar defined in showing this grammar extension, extending the grammar defined in
<xref target='RFC5104'/>.</t> <xref target="RFC5104" format="default" sectionFormat="of" derivedContent=
"RFC5104"/>.</t>
<figure anchor="lrr_grammar" title="Syntax of the &quot;lrr&quot; <figure anchor="lrr_grammar" align="left" suppress-title="false" pn="figur
ccm"> e-9">
<artwork type="abnf"> <name slugifiedName="name-syntax-of-the-lrr-ccm">Syntax of the "lrr" CCM
</name>
<sourcecode type="abnf" markers="false" pn="section-6-3.1">
rtcp-fb-ccm-param =/ SP "lrr" ; Layer Refresh Request rtcp-fb-ccm-param =/ SP "lrr" ; Layer Refresh Request
</artwork> </sourcecode>
</figure> </figure>
<t indent="0" pn="section-6-4">The Offer-Answer considerations defined in
<t>The Offer-Answer considerations defined in <xref target="RFC5104" sectionFormat="of" section="7.2" format="default
<xref target='RFC5104' /> Section 7.2 apply.</t> " derivedLink="https://rfc-editor.org/rfc/rfc5104#section-7.2" derivedContent="R
</section> FC5104"/> apply.</t>
</section>
<section anchor="securityConsiderations" title="Security Considerations"> <section anchor="securityConsiderations" numbered="true" toc="include" remov
<t>All the security considerations of <xref target="RFC5104">FIR eInRFC="false" pn="section-7">
<name slugifiedName="name-security-considerations">Security Considerations
</name>
<t indent="0" pn="section-7-1">All the security considerations of <xref ta
rget="RFC5104" format="default" sectionFormat="of" derivedContent="RFC5104">FIR
feedback packets</xref> apply to LRR feedback packets as well. feedback packets</xref> apply to LRR feedback packets as well.
Additionally, media senders receiving LRR feedback packets MUST Additionally, media senders receiving LRR feedback packets <bcp14>MUST< /bcp14>
validate that the payload types and layer indices they are validate that the payload types and layer indices they are
receiving are valid for the stream they are currently sending, receiving are valid for the stream they are currently sending,
and discard the requests if not.</t> and discard the requests if not.</t>
</section> </section>
<section anchor="IANAConsiderations" numbered="true" toc="include" removeInR
<section anchor="IANAConsiderations" title="IANA Considerations"> FC="false" pn="section-8">
<t>This document defines a new entry to the "Codec Control <name slugifiedName="name-iana-considerations">IANA Considerations</name>
Messages" subregistry of the "Session Description Protocol (SDP) <t indent="0" pn="section-8-1">This document defines a new entry to the "C
Parameters" registry, according to the following data:</t> odec Control
Messages" registry of the "Session Description Protocol (SDP)
<t> Parameters" registry group, according to the following data:</t>
<list style='hanging'> <dl newline="false" spacing="compact" indent="3" pn="section-8-2">
<t hangText='Value name:'>lrr</t> <dt pn="section-8-2.1">Value Name:</dt>
<t hangText='Long name:'>Layer Refresh Request Command</t> <dd pn="section-8-2.2">lrr</dd>
<t hangText='Usable with:'>ccm</t> <dt pn="section-8-2.3">Long Name:</dt>
<t hangText='Mux:'>IDENTICAL-PER-PT</t> <dd pn="section-8-2.4">Layer Refresh Request Command</dd>
<t hangText='Reference:'>RFC &rfc.number;</t> <dt pn="section-8-2.5">Usable with:</dt>
</list> <dd pn="section-8-2.6">ccm</dd>
</t> <dt pn="section-8-2.7">Mux:</dt>
<dd pn="section-8-2.8">IDENTICAL-PER-PT</dd>
<t>This document also defines a new entry to the "FMT Values for <dt pn="section-8-2.9">Reference:</dt>
PSFB Payload Types" subregistry of the "Real-Time Transport <dd pn="section-8-2.10">RFC 9627</dd>
Protocol (RTP) Parameters" registry, according to the following </dl>
<t indent="0" pn="section-8-3">This document also defines a new entry to t
he "FMT Values for
PSFB Payload Types" registry of the "Real-Time Transport
Protocol (RTP) Parameters" registry group, according to the following
data:</t> data:</t>
<dl newline="false" spacing="compact" indent="3" pn="section-8-4">
<t> <dt pn="section-8-4.1">Name:</dt>
<list style='hanging'> <dd pn="section-8-4.2">LRR</dd>
<t hangText='Name:'>LRR</t> <dt pn="section-8-4.3">Long Name:</dt>
<t hangText='Long Name:'>Layer Refresh Request Command</t> <dd pn="section-8-4.4">Layer Refresh Request Command</dd>
<t hangText='Value:'>TBD</t> <dt pn="section-8-4.5">Value:</dt>
<t hangText='Reference:'>RFC &rfc.number;</t> <dd pn="section-8-4.6">10</dd>
</list> <dt pn="section-8-4.7">Reference:</dt>
</t> <dd pn="section-8-4.8">RFC 9627</dd>
</dl>
</section> </section>
</middle> </middle>
<back> <back>
<references title='Normative References'> <references pn="section-9">
&rfc2119; <name slugifiedName="name-references">References</name>
<references pn="section-9.1">
&rfc3550; <name slugifiedName="name-normative-references">Normative References</na
me>
&rfc4585; <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
&rfc5104; <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
&rfc5234; le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
&rfc6190; <date month="March" year="1997"/>
<abstract>
&rfc7741; <t indent="0">In many standards track documents several words are
used to signify the requirements in the specification. These words are often cap
&rfc7798; italized. This document defines these words as they should be interpreted in IET
F documents. This document specifies an Internet Best Current Practices for the
&framemarking; Internet Community, and requests discussion and suggestions for improvements.</t
</references> >
</abstract>
<references title='Informative References'> </front>
<seriesInfo name="BCP" value="14"/>
&rfc7656; <seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
&rfc8082; </reference>
<reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3
&vp9rtp; 550" quoteTitle="true" derivedAnchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne
"/>
<author fullname="S. Casner" initials="S." surname="Casner"/>
<author fullname="R. Frederick" initials="R." surname="Frederick"/>
<author fullname="V. Jacobson" initials="V." surname="Jacobson"/>
<date month="July" year="2003"/>
<abstract>
<t indent="0">This memorandum describes RTP, the real-time transpo
rt protocol. RTP provides end-to-end network transport functions suitable for ap
plications transmitting real-time data, such as audio, video or simulation data,
over multicast or unicast network services. RTP does not address resource reser
vation and does not guarantee quality-of- service for real-time services. The da
ta transport is augmented by a control protocol (RTCP) to allow monitoring of th
e data delivery in a manner scalable to large multicast networks, and to provide
minimal control and identification functionality. RTP and RTCP are designed to
be independent of the underlying transport and network layers. The protocol supp
orts the use of RTP-level translators and mixers. Most of the text in this memor
andum is identical to RFC 1889 which it obsoletes. There are no changes in the p
acket formats on the wire, only changes to the rules and algorithms governing ho
w the protocol is used. The biggest change is an enhancement to the scalable tim
er algorithm for calculating when to send RTCP packets in order to minimize tran
smission in excess of the intended rate when many participants join a session si
multaneously. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="64"/>
<seriesInfo name="RFC" value="3550"/>
<seriesInfo name="DOI" value="10.17487/RFC3550"/>
</reference>
<reference anchor="RFC4585" target="https://www.rfc-editor.org/info/rfc4
585" quoteTitle="true" derivedAnchor="RFC4585">
<front>
<title>Extended RTP Profile for Real-time Transport Control Protocol
(RTCP)-Based Feedback (RTP/AVPF)</title>
<author fullname="J. Ott" initials="J." surname="Ott"/>
<author fullname="S. Wenger" initials="S." surname="Wenger"/>
<author fullname="N. Sato" initials="N." surname="Sato"/>
<author fullname="C. Burmeister" initials="C." surname="Burmeister"/
>
<author fullname="J. Rey" initials="J." surname="Rey"/>
<date month="July" year="2006"/>
<abstract>
<t indent="0">Real-time media streams that use RTP are, to some de
gree, resilient against packet losses. Receivers may use the base mechanisms of
the Real-time Transport Control Protocol (RTCP) to report packet reception stati
stics and thus allow a sender to adapt its transmission behavior in the mid-term
. This is the sole means for feedback and feedback-based error repair (besides a
few codec-specific mechanisms). This document defines an extension to the Audio
-visual Profile (AVP) that enables receivers to provide, statistically, more imm
ediate feedback to the senders and thus allows for short-term adaptation and eff
icient feedback-based repair mechanisms to be implemented. This early feedback p
rofile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves sca
lability to large groups. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4585"/>
<seriesInfo name="DOI" value="10.17487/RFC4585"/>
</reference>
<reference anchor="RFC5104" target="https://www.rfc-editor.org/info/rfc5
104" quoteTitle="true" derivedAnchor="RFC5104">
<front>
<title>Codec Control Messages in the RTP Audio-Visual Profile with F
eedback (AVPF)</title>
<author fullname="S. Wenger" initials="S." surname="Wenger"/>
<author fullname="U. Chandra" initials="U." surname="Chandra"/>
<author fullname="M. Westerlund" initials="M." surname="Westerlund"/
>
<author fullname="B. Burman" initials="B." surname="Burman"/>
<date month="February" year="2008"/>
<abstract>
<t indent="0">This document specifies a few extensions to the mess
ages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful
primarily in conversational multimedia scenarios where centralized multipoint fu
nctionalities are in use. However, some are also usable in smaller multicast env
ironments and point-to-point calls.</t>
<t indent="0">The extensions discussed are messages related to the
ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Medi
a Stream Bit Rate, and Temporal-Spatial Trade-off. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5104"/>
<seriesInfo name="DOI" value="10.17487/RFC5104"/>
</reference>
<reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5
234" quoteTitle="true" derivedAnchor="RFC5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="C
rocker"/>
<author fullname="P. Overell" initials="P." surname="Overell"/>
<date month="January" year="2008"/>
<abstract>
<t indent="0">Internet technical specifications often need to defi
ne a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF)
, called Augmented BNF (ABNF), has been popular among many Internet specificatio
ns. The current specification documents ABNF. It balances compactness and simpli
city with reasonable representational power. The differences between standard BN
F and ABNF involve naming rules, repetition, alternatives, order-independence, a
nd value ranges. This specification also supplies additional rule definitions an
d encoding for a core lexical analyzer of the type common to several Internet sp
ecifications. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="RFC6190" target="https://www.rfc-editor.org/info/rfc6
190" quoteTitle="true" derivedAnchor="RFC6190">
<front>
<title>RTP Payload Format for Scalable Video Coding</title>
<author fullname="S. Wenger" initials="S." surname="Wenger"/>
<author fullname="Y.-K. Wang" initials="Y.-K." surname="Wang"/>
<author fullname="T. Schierl" initials="T." surname="Schierl"/>
<author fullname="A. Eleftheriadis" initials="A." surname="Eleftheri
adis"/>
<date month="May" year="2011"/>
<abstract>
<t indent="0">This memo describes an RTP payload format for Scalab
le Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which
is technically identical to Amendment 3 of ISO/IEC International Standard 14496
-10. The RTP payload format allows for packetization of one or more Network Abst
raction Layer (NAL) units in each RTP packet payload, as well as fragmentation o
f a NAL unit in multiple RTP packets. Furthermore, it supports transmission of a
n SVC stream over a single as well as multiple RTP sessions. The payload format
defines a new media subtype name "H264-SVC", but is still backward compatible to
RFC 6184 since the base layer, when encapsulated in its own RTP stream, must us
e the H.264 media subtype name ("H264") and the packetization method specified i
n RFC 6184. The payload format has wide applicability in videoconferencing, Inte
rnet video streaming, and high-bitrate entertainment-quality video, among others
. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6190"/>
<seriesInfo name="DOI" value="10.17487/RFC6190"/>
</reference>
<reference anchor="RFC7741" target="https://www.rfc-editor.org/info/rfc7
741" quoteTitle="true" derivedAnchor="RFC7741">
<front>
<title>RTP Payload Format for VP8 Video</title>
<author fullname="P. Westin" initials="P." surname="Westin"/>
<author fullname="H. Lundin" initials="H." surname="Lundin"/>
<author fullname="M. Glover" initials="M." surname="Glover"/>
<author fullname="J. Uberti" initials="J." surname="Uberti"/>
<author fullname="F. Galligan" initials="F." surname="Galligan"/>
<date month="March" year="2016"/>
<abstract>
<t indent="0">This memo describes an RTP payload format for the VP
8 video codec. The payload format has wide applicability, as it supports applica
tions from low-bitrate peer-to-peer usage to high-bitrate video conferences.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7741"/>
<seriesInfo name="DOI" value="10.17487/RFC7741"/>
</reference>
<reference anchor="RFC7798" target="https://www.rfc-editor.org/info/rfc7
798" quoteTitle="true" derivedAnchor="RFC7798">
<front>
<title>RTP Payload Format for High Efficiency Video Coding (HEVC)</t
itle>
<author fullname="Y.-K. Wang" initials="Y.-K." surname="Wang"/>
<author fullname="Y. Sanchez" initials="Y." surname="Sanchez"/>
<author fullname="T. Schierl" initials="T." surname="Schierl"/>
<author fullname="S. Wenger" initials="S." surname="Wenger"/>
<author fullname="M. M. Hannuksela" initials="M. M." surname="Hannuk
sela"/>
<date month="March" year="2016"/>
<abstract>
<t indent="0">This memo describes an RTP payload format for the vi
deo coding standard ITU-T Recommendation H.265 and ISO/IEC International Standar
d 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed
by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format
allows for packetization of one or more Network Abstraction Layer (NAL) units i
n each RTP packet payload as well as fragmentation of a NAL unit into multiple R
TP packets. Furthermore, it supports transmission of an HEVC bitstream over a si
ngle stream as well as multiple RTP streams. When multiple RTP streams are used,
a single transport or multiple transports may be utilized. The payload format h
as wide applicability in videoconferencing, Internet video streaming, and high-b
itrate entertainment-quality video, among others.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7798"/>
<seriesInfo name="DOI" value="10.17487/RFC7798"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by clari
fying that only UPPERCASE usage of the key words have the defined special meanin
gs.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC9626" target="https://www.rfc-editor.org/info/rfc9
626" quoteTitle="true" derivedAnchor="RFC9626">
<front>
<title>Video Frame Marking RTP Header Extension</title>
<author initials="M." surname="Zanaty" fullname="Mo Zanaty">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<author initials="E." surname="Berger" fullname="Espen Berger">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<author initials="S." surname="Nandakumar" fullname="Suhas Nandakuma
r">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<date month="March" year="2025"/>
</front>
<seriesInfo name="RFC" value="9626"/>
<seriesInfo name="DOI" value="10.17487/RFC9626"/>
</reference>
</references>
<references pn="section-9.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="RFC7656" target="https://www.rfc-editor.org/info/rfc7
656" quoteTitle="true" derivedAnchor="RFC7656">
<front>
<title>A Taxonomy of Semantics and Mechanisms for Real-Time Transpor
t Protocol (RTP) Sources</title>
<author fullname="J. Lennox" initials="J." surname="Lennox"/>
<author fullname="K. Gross" initials="K." surname="Gross"/>
<author fullname="S. Nandakumar" initials="S." surname="Nandakumar"/
>
<author fullname="G. Salgueiro" initials="G." surname="Salgueiro"/>
<author fullname="B. Burman" initials="B." role="editor" surname="Bu
rman"/>
<date month="November" year="2015"/>
<abstract>
<t indent="0">The terminology about, and associations among, Real-
time Transport Protocol (RTP) sources can be complex and somewhat opaque. This d
ocument describes a number of existing and proposed properties and relationships
among RTP sources and defines common terminology for discussing protocol entiti
es and their relationships.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7656"/>
<seriesInfo name="DOI" value="10.17487/RFC7656"/>
</reference>
<reference anchor="RFC8082" target="https://www.rfc-editor.org/info/rfc8
082" quoteTitle="true" derivedAnchor="RFC8082">
<front>
<title>Using Codec Control Messages in the RTP Audio-Visual Profile
with Feedback with Layered Codecs</title>
<author fullname="S. Wenger" initials="S." surname="Wenger"/>
<author fullname="J. Lennox" initials="J." surname="Lennox"/>
<author fullname="B. Burman" initials="B." surname="Burman"/>
<author fullname="M. Westerlund" initials="M." surname="Westerlund"/
>
<date month="March" year="2017"/>
<abstract>
<t indent="0">This document updates RFC 5104 by fixing a shortcomi
ng in the specification language of the Codec Control Message Full Intra Request
(FIR) description when using it with layered codecs. In particular, a decoder r
efresh point needs to be sent by a media sender when a FIR is received on any la
yer of the layered bitstream, regardless of whether those layers are being sent
in a single or in multiple RTP flows. The other payload-specific feedback messag
es defined in RFC 5104 and RFC 4585 (which was updated by RFC 5506) have also be
en analyzed, and no corresponding shortcomings have been found.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8082"/>
<seriesInfo name="DOI" value="10.17487/RFC8082"/>
</reference>
<reference anchor="RFC9628" target="https://www.rfc-editor.org/info/rfc9
628" quoteTitle="true" derivedAnchor="RFC9628">
<front>
<title>RTP Payload Format for VP9 Video</title>
<author initials="J." surname="Uberti" fullname="Justin Uberti">
<organization showOnFrontPage="true">OpenAI</organization>
</author>
<author initials="S." surname="Holmer" fullname="Stefan Holmer">
<organization showOnFrontPage="true">Google, Inc.</organization>
</author>
<author initials="M." surname="Flodman" fullname="Magnus Flodman">
<organization showOnFrontPage="true">Google, Inc.</organization>
</author>
<author initials="D." surname="Hong" fullname="Danny Hong">
<organization showOnFrontPage="true">Vidyo, Inc.</organization>
</author>
<author initials="J." surname="Lennox" fullname="Jonathan Lennox">
<organization showOnFrontPage="true">8x8, Inc. / Jitsi</organizati
on>
</author>
<date month="March" year="2025"/>
</front>
<seriesInfo name="RFC" value="9628"/>
<seriesInfo name="DOI" value="10.17487/RFC9628"/>
</reference>
</references>
</references> </references>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.a">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author fullname="Jonathan Lennox" initials="J." surname="Lennox">
<organization abbrev="8x8 / Jitsi" showOnFrontPage="true">8x8, Inc. / Ji
tsi</organization>
<address>
<postal>
<city>Jersey City</city>
<region>NJ</region>
<code>07302</code>
<country>United States of America</country>
</postal>
<email>jonathan.lennox@8x8.com</email>
</address>
</author>
<author fullname="Danny Hong" initials="D." surname="Hong">
<organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organ
ization>
<address>
<postal>
<street>315 Hudson St.</street>
<city>New York</city>
<region>NY</region>
<code>10013</code>
<country>United States of America</country>
</postal>
<email>dannyhong@google.com</email>
</address>
</author>
<author fullname="Justin Uberti" initials="J." surname="Uberti">
<organization showOnFrontPage="true">OpenAI</organization>
<address>
<postal>
<street>1455 3rd St</street>
<city>San Francisco</city>
<region>CA</region>
<code>94158</code>
<country>United States of America</country>
</postal>
<email>justin@uberti.name</email>
</address>
</author>
<author fullname="Stefan Holmer" initials="S." surname="Holmer">
<organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organ
ization>
<address>
<postal>
<street>Kungsbron 2</street>
<code>111 22</code>
<city>Stockholm</city>
<country>Sweden</country>
</postal>
<email>holmer@google.com</email>
</address>
</author>
<author fullname="Magnus Flodman" initials="M." surname="Flodman">
<organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organ
ization>
<address>
<postal>
<street>Kungsbron 2</street>
<code>111 22</code>
<city>Stockholm</city>
<country>Sweden</country>
</postal>
<email>mflodman@google.com</email>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
<!-- LocalWords: PictureID DCT Hadamard WHT SSRC CSRC pyld hdr FI VER RPSI
-->
<!-- LocalWords: stPartitionSize SLI SDP AVPF SRTP IANA PID PICIDX TID
-->
 End of changes. 84 change blocks. 
641 lines changed or deleted 1155 lines changed or added

This html diff was produced by rfcdiff 1.48.