<?xml version="1.0"encoding="US-ASCII"?>encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYrfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITYrfc3264 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml">zwsp "​"> <!ENTITYrfc3550 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml">nbhy "‑"> <!ENTITYrfc3551 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3551.xml"> <!ENTITY rfc3711 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml"> <!ENTITY rfc3984 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3984.xml"> <!ENTITY rfc4855 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4855.xml"> <!ENTITY rfc4585 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml"> <!ENTITY rfc5104 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5104.xml"> <!ENTITY rfc5124 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5124.xml"> <!ENTITY rfc6386 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6386.xml"> <!ENTITY rfc6838 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"> <!ENTITY rfc7201 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7201.xml"> <!ENTITY rfc7202 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7202.xml"> <!ENTITY rfc7667 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7667.xml"> <!ENTITY rfc8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY rfc8866 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8866.xml"> <!ENTITY lrr SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-avtext-lrr.xml">wj "⁠"> ]> <rfccategory="std"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-payload-vp9-16"ipr="trust200902"> <?rfc symrefs="yes" ?> <?rfc sortrefs="yes" ?> <!-- alphabetize the references --> <?rfc comments="no"?> <!-- show comments --> <?rfc inline="yes" ?> <!-- comments are inline --> <?rfc toc="yes" ?> <!-- generate table of contents -->number="9628" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3"> <front> <title abbrev="RTP Payload Format for VP9">RTP Payload Format for VP9 Video</title> <seriesInfo name="RFC" value="9628"/> <author fullname="Justin Uberti" initials="J." surname="Uberti"> <organization abbrev="Google">Google, Inc.</organization> <address> <postal> <street>747 6th Street South</street> <city>Kirkland</city> <region>WA</region> <code>98033</code><country>USA</country><country>United States of America</country> </postal> <email>justin@uberti.name</email> </address> </author> <author fullname="Stefan Holmer" initials="S." surname="Holmer"> <organization abbrev="Google">Google, Inc.</organization> <address> <postal> <street>Kungsbron 2</street> <code>111 22</code> <city>Stockholm</city> <country>Sweden</country> </postal> <email>holmer@google.com</email> </address> </author> <author fullname="Magnus Flodman" initials="M." surname="Flodman"> <organization abbrev="Google">Google, Inc.</organization> <address> <postal> <street>Kungsbron 2</street> <code>111 22</code> <city>Stockholm</city> <country>Sweden</country> </postal> <email>mflodman@google.com</email> </address> </author> <author fullname="Danny Hong" initials="D." surname="Hong"> <organization abbrev="Google">Google, Inc.</organization> <address> <postal> <street>1585 Charleston Road</street> <city>Mountain View</city> <region>CA</region> <code>94043</code><country>US</country><country>United States of America</country> </postal> <email>dannyhong@google.com</email> </address> </author> <author fullname="Jonathan Lennox" initials="J." surname="Lennox"> <organization abbrev="8x8 / Jitsi">8x8, Inc. / Jitsi</organization> <address> <postal> <street/> <city>Jersey City</city> <region>NJ</region> <code>07302</code><country>US</country><country>United States of America</country> </postal> <email>jonathan.lennox@8x8.com</email> </address> </author><date/><date year="2024" month="August" /> <area>RAI</area> <workgroup>AVTCore Working Group</workgroup><keyword>RFC</keyword> <keyword>Request for Comments</keyword><keyword>RTP</keyword> <keyword>VP9</keyword> <keyword>WebM</keyword> <abstract> <t>This specification describes an RTP payload format for the VP9 video codec. The payload format has wideapplicability,applicability as it supports applications from lowbit-ratebitrate peer-to-peerusage,usage to highbit-ratebitrate video conferences. It includes provisions for temporal and spatial scalability.</t> </abstract> </front> <middle> <section anchor="intro"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>Thisspecificationdocument describes an <xreftarget="RFC3550">RTP</xref>target="RFC3550" format="default">RTP</xref> payload specification applicable to the transmission of video streams encoded using the VP9 video codec <xreftarget="VP9-BITSTREAM"/>.target="VP9-BITSTREAM" format="default"/>. The format described in this document can be used both in peer-to-peer and video conferencing applications.</t> <t>The VP9 video codec was developed byGoogle,Google and is the successor to its earlier <xreftarget="RFC6386">VP8</xref>target="RFC6386" format="default">VP8</xref> codec. Above the compression improvements and other general enhancementsaboveto VP8, VP9 is also designed in a way that allowsspatially-scalablespatially scalable video encoding.</t> </section> <!--[rfced] Please note that we have updated the title of Section 2 to more accurately describe its contents. Please let us know any objections.--> <section anchor="conventions"title="Conventions, Definitions and Acronyms"> <t>Thenumbered="true" toc="default"> <name>Conventions</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <section anchor="mediaFormatDescription"title="Medianumbered="true" toc="default"> <name>Media FormatDescription">Description</name> <t>The VP9 codec can maintain up to eight reference frames, of which up to three can be referenced by any new frame.</t> <t>VP9 also allows a frame to use another frame of a different resolution as a reference frame. (Specifically, a frame may use any references whose width and height are between 1/16th that of the current frame and twice that of the current frame, inclusive.) This allows internal resolution changes without requiring the use ofkey frames.</t>keyframes.</t> <t>These features together enable an encoder to implement various forms of coarse-grained scalability, including temporal,spatialspatial, and quality scalability modes, as well as combinations of these, without the need for explicit scalable coding tools.</t> <t>Temporal layers define different frame rates of video; spatial and quality layers define different and possibly dependent representations of a single input frame. Spatial layers allow a frame to be encoded at different resolutions, whereas quality layers allow a frame to be encoded at the same resolution but at different qualities(and thus(and, thus, with different amounts of coding error). VP9 supports quality layers as spatial layers without any resolution changes; hereinafter, the term "spatial layer" is used to represent both spatial and quality layers.</t> <t>This payload format specification defines how such temporal and spatial scalability layers can be described and communicated.</t> <t>Temporal and spatial scalability layers are associated with non-negative integer IDs. The lowest layer of either type has an ID of0,0 and is sometimes referred to as the "base" temporal or spatial layer.</t> <t>Layers are designed, andMUST<bcp14>MUST</bcp14> be encoded, such that if any layer, and all higher layers, are removed from the bitstream along either the spatial or temporal dimension, the remaining bitstream is still correctly decodable.</t> <!--[rfced] Might replacing the slash in the following with "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 instant in time.AThus, a picturethusconsists of one or more frames, encoding different spatial layers.</t> <t>Within a picture, a frame withspatial layerspatial-layer ID equal to SID, where SID>> 0, can depend on a frame of the same picture with a lowerspatial layerspatial-layer ID. This "inter-layer" dependency can result in additional coding gain compared to the case where only traditional "inter-picture" dependency is used, where a frame depends on a previously coded frame in time. For simplicity, this payload format assumes that, within a picture and if inter-layer dependency is used, aspatial layerspatial-layer SID frame can depend only on the immediately previousspatial layerspatial-layer SID-1 frame, when S>> 0. Additionally, if inter-picture dependency is used, aspatial layerspatial-layer SID frame is assumed to only depend on a previously codedspatial layerspatial-layer SID frame.</t> <!-- [rfced] FYI: We've updated the following sentence by adding "a" before "previously coded frame in time". Please let us know if this changes the intended meaning. Original: 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 previously coded frame in time. 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 aspatial layerspatial-layer SID frame depends on thespatial layerspatial-layer SID-1 frame. Given the D bit, a receiver only needs to additionally know the inter-picture dependency structure for a givenspatial layerspatial-layer frame in order to determine its decodability. Two modes of describing the inter-picture dependency structure are possible: "flexible mode" and "non-flexible mode". An encoder can only switch between the two on the first packet of akey framekeyframe withtemporal layera temporal-layer ID equal to 0.</t> <t>In flexible mode, each packet can contain up to3three reference indices, which identify all frames referenced by the frame transmitted in the current packet for inter-picture prediction. This (along with the D bit) enables a receiver to identify if a frame is decodable or not and helps it understand thetemporal layertemporal-layer structure. Since this is signaled in eachpacketpacket, it makes it possible to have very flexibletemporal layer hierarchies,temporal-layer hierarchies and scalabilitystructuresstructures, which are changing dynamically.</t> <t>In non-flexible mode, frames are encoded using a fixed, recurring pattern of dependencies; the set of pictures that recur in this pattern is known as aPicture Group (PG)."Picture Group" (or "PG"). In this mode, the inter-picture dependencies (the reference indices) of thePicture Group MUSTPG <bcp14>MUST</bcp14> be pre-specified as part of thescalability structureScalability Structure (SS) data. Each packet has an index to refer to one of the described pictures in thePG,PG from which the pictures referenced by the picture transmitted in the current packet for inter-picture prediction can be identified.</t><t>(Note:<!-- [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 "PictureGroup",Group" or "PG", as used in this document, is not the same thing as the term "Group of Pictures" as it is traditionally used in video coding,i.e.i.e., to mean anindependently-decoadableindependently decodable run of pictures beginning with akeyframe.)</t>keyframe.</t> <t>The SS data can also be used to specify the resolution of each spatial layer present in the VP9 stream for both flexible and non-flexible modes.</t> </section> <section anchor="payloadFormat"title="Payload Format">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. --> <t>This section describes how the encoded VP9 bitstream is encapsulated in RTP. To handle networklosseslosses, usage of RTP/AVPF <xreftarget="RFC4585"/>target="RFC4585" format="default"/> isRECOMMENDED.<bcp14>RECOMMENDED</bcp14>. All integer fields in the specifications are encoded as unsigned integers in network octet order.</t> <section anchor="RTPHeaderUsage"title="RTPnumbered="true" toc="default"> <name>RTP HeaderUsage"> <figure anchor="figureRTPHeader"> <preamble>TheUsage</name> <t keepWithNext="true">The general RTP payload format for VP9 is depictedbelow.</preamble> <artwork><![CDATA[below.</t> <figure anchor="figureRTPHeader" title="General RTP Payload Format for VP"> <artwork type="" align="left" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | VP9 payload descriptor (integer #octets) | : : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | + | : VP9 payload : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork><postamble>The</figure> <t keepWithPrevious="true">See <xref target="VP9payloadDescriptor" format="default"/> for more information on the VP9 payloaddescriptor will be described in <xref target="VP9payloadDescriptor"/>;descriptor; the VP9 payload is described in <xreftarget="VP9-BITSTREAM"/>. OPTIONALtarget="VP9-BITSTREAM" format="default"/>. <bcp14>OPTIONAL</bcp14> RTP paddingMUST NOT<bcp14>MUST NOT</bcp14> be included unless the P bit isset.</postamble> </figure> <t><list style="hanging"> <t hangText="Markerset.</t> <!--[rfced] [*AD] In the following, we believe restructuring the text may clarify the applicability of the BCP 14 keywords (are both parts of the sentence MUSTs?). Please review. Instance 1: Original: Marker bit(M):">MUST(M): MUST be set to 1 for the final packet of the highest spatial layer frame (the final packet of the picture), and 0 otherwise. Perhap A: Marker bit (M): This bit MUST be set to 1 for the final packet of the highest spatial-layer frame (the final packet of the picture); otherwise, it MUST be 0. Perhaps B: Marker bit (M): This bit MUST be set to 1 for the final packet of the highest spatial-layer frame (the final packet of the picture); otherwise, it is 0. 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 picture, this bit will have the same value as the E bit describedbelow.in <xref target="VP9payloadDescriptor"/>. Note this bitMUST<bcp14>MUST</bcp14> be set to 1 for the targetspatial layerspatial-layer frame if a stream is being rewritten to remove higher spatiallayers.</t> <t hangText="Payloadlayers.</dd> <dt>Payload Type(PT):">In(PT):</dt> <dd>In line with the policy inSection 3 of<xreftarget='RFC3551'/>,target="RFC3551" sectionFormat="of" section="3" format="default"/>, applications using the VP9 RTP payload profileMUST<bcp14>MUST</bcp14> assign a dynamic payload type number to be used in each RTP session and provide a mechanism to indicate the mapping. See <xreftarget="SDPParameters"/>target="SDPParameters" format="default"/> for the mechanism to be used with the <xreftarget='RFC8866'>Sessiontarget="RFC8866" format="default">Session Description Protocol(SDP)</xref>.</t> <t hangText="Timestamp:">The(SDP)</xref>.</dd> <dt>Timestamp:</dt> <dd>The <xreftarget="RFC3550">RTPtarget="RFC3550" format="default">RTP timestamp</xref> indicates the time when the input frame was sampled, at a clock rate of 90 kHz. If the input picture is encoded withmultiple layermultiple-layer frames, all of the frames of the pictureMUST<bcp14>MUST</bcp14> have the sametimestamp.</t> <t>Iftimestamp.</dd> <dt/> <dd>If a frame has the VP9 show_frame field set to 0 (i.e., it is meant only to populate a referencebuffer,buffer without beingoutput)output), its timestampMAY<bcp14>MAY</bcp14> alternatively be set to be the same as the subsequent frame with show_frame equal to 1. (This will be convenient for playing out pre-encoded content packaged with VP9 "superframes", which typically bundle show_frame==0 frames with a subsequent show_frame==1 frame.) Every frame with show_frame==1, however,MUST<bcp14>MUST</bcp14> have a unique timestamp modulo the2^322<sup>32</sup> wrap of thefield.</t> </list></t>field.</dd> </dl> <t>The remaining RTP Fixed Header Fields (V, P, X, CC, sequence number,SSRCSSRC, and CSRC identifiers) are used as specified inSection 5.1 of<xreftarget="RFC3550"/>.</t>target="RFC3550" sectionFormat="of" section="5.1" format="default"/>.</t> </section> <section anchor="VP9payloadDescriptor"title="VP9numbered="true" toc="default"> <name>VP9 PayloadDescriptor"> <figure anchor="figureVP9payloadDescriptor"> <preamble>InDescriptor</name> <!--[rfced] Section 4.2: It seems the descriptions following Figure 3 apply to both Figures 2 and 3. If that is so, might a note of this appear somewhere earlier in that section for the ease of the reader?--> <t keepWithNext="true">In flexible mode (with the F bit below set to 1), the first octets after the RTP header are the VP9 payload descriptor, with the followingstructure.</preamble> <artwork><![CDATA[structure.</t> <figure anchor="figureVP9payloadDescriptor" title="Flexible Mode Format for VP9 Payload Descriptor"> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |I|P|L|F|B|E|V|Z| (REQUIRED) +-+-+-+-+-+-+-+-+ I: |M| PICTURE ID | (REQUIRED) +-+-+-+-+-+-+-+-+ M: | EXTENDED PID | (RECOMMENDED) +-+-+-+-+-+-+-+-+ L: | TID |U| SID |D| (Conditionally RECOMMENDED) +-+-+-+-+-+-+-+-+ -\ P,F: | P_DIFF |N| (Conditionally REQUIRED) - up to 3 times +-+-+-+-+-+-+-+-+ -/ V: | SS | | .. | +-+-+-+-+-+-+-+-+ ]]></artwork> </figure><figure anchor="figureVP9payloadDescriptorNonFlexible"> <preamble>In<t keepWithNext="true">In non-flexible mode (with the F bit below set to 0), the first octets after the RTP header are the VP9 payload descriptor, with the followingstructure.</preamble> <artwork><![CDATA[structure.</t> <figure anchor="figureVP9payloadDescriptorNonFlexible" title="Non-flexible Mode Format for VP9 Payload Descriptor"> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |I|P|L|F|B|E|V|Z| (REQUIRED) +-+-+-+-+-+-+-+-+ I: |M| PICTURE ID | (RECOMMENDED) +-+-+-+-+-+-+-+-+ M: | EXTENDED PID | (RECOMMENDED) +-+-+-+-+-+-+-+-+ L: | TID |U| SID |D| (Conditionally RECOMMENDED) +-+-+-+-+-+-+-+-+ | TL0PICIDX | (Conditionally REQUIRED) +-+-+-+-+-+-+-+-+ V: | SS | | .. | +-+-+-+-+-+-+-+-+ ]]></artwork> </figure><t><list style="hanging"> <t hangText="I:">Picture<dl newline="false" spacing="normal"> <dt>I:</dt> <dd>Picture ID (PID) present. When set toone,1, theOPTIONAL<bcp14>OPTIONAL</bcp14> PIDMUST<bcp14>MUST</bcp14> be present after the mandatory first octet and specified as below. Otherwise, PIDMUST NOT<bcp14>MUST NOT</bcp14> be present. If the V bit was set in the stream's most recent start of a keyframe(i.e.(i.e., the SS field was present) and the F bit is set to 0(i.e.(i.e., non-flexible scalability mode is in use), then this bitMUST<bcp14>MUST</bcp14> be set on everypacket.</t> <t hangText="P:">Inter-picturepacket.</dd> <dt>P:</dt> <dd>Inter-picture predicted frame. When set tozero,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 lowerspatial layerspatial-layer frame. PSHOULD<bcp14>SHOULD</bcp14> also be set tozero0 when encoding a layer synchronization frame in response toana <xreftarget='I-D.ietf-avtext-lrr'>LRR</xref>target="RFC9627" format="default">Layer Refresh Request (LRR)</xref> message (see <xreftarget='LRR'/>).target="LRR" format="default"/>). When P is set tozero,0, the TID field (described below)MUST<bcp14>MUST</bcp14> also be set to 0 (if present). Note that the P bit does not forbid intra-picture, inter-layer prediction from earlier frames of the same picture, ifany.</t> <t hangText="L:">Layerany.</dd> <dt>L:</dt> <dd>Layer indices present. When set toone,1, the one or two octets following the mandatory first octet and the PID (if present) is as described by "Layer indices" below. If the F bit (described below) is set to 1 (indicating flexible mode), then only one octet is present for the layer indices.OtherwiseOtherwise, if the F bit is set to 0 (indicating non-flexible mode), then two octets are present for the layerindices.</t> <t hangText="F:">Flexibleindices.</dd> <dt>F:</dt> <dd>Flexible mode.FWhen set toone1, this indicates flexiblemode andmode; if the P bit is also set toone,1, then the octets following the mandatory first octet, the PID, and layer indices (if present) are as described by "Reference indices" below. ThisMUSTbit <bcp14>MUST</bcp14> only be set to 1 if the I bit is also set toone;1; if the I bit is set tozero,0, then thisMUSTbit <bcp14>MUST</bcp14> also be set tozero0 and ignored by receivers. (Flexible mode's Reference indices are defined as offsets from the Picture ID field, so they would have no meaning if I were not set.) The value ofthisthe F bitMUST<bcp14>MUST</bcp14> only change on the first packet of a key picture. Akey picture"key picture" is a picture whose basespatial layerspatial-layer frame is akey frame,keyframe, andwhichthus one which completely resets the encoder state. This packet will have its P bit equal tozero,0, SID or L bit (described below) equal tozero,0, and B bit (described below) equal to1.</t> <t hangText="B:">Start1.</dd> <dt>B:</dt> <dd>Start of a frame.MUSTThis bit <bcp14>MUST</bcp14> be set to 1 if the first payload octet of the RTP packet is the beginning of a new VP9frame, and MUST NOTframe; otherwise, it <bcp14>MUST NOT</bcp14> be1 otherwise.1. Note that this frame might not be the first frame of apicture.</t> <t hangText="E:">Endpicture.</dd> <dt>E:</dt> <dd>End of a frame.MUSTThis bit <bcp14>MUST</bcp14> be set to 1 for the final RTP packet of a VP9 frame, and 0 otherwise. This enables a decoder to finish decoding the frame, where it otherwise may need to wait for the next packet to explicitly know that the frame is complete. Note that, if spatial scalability is in use, more frames from the same picture may follow; see the description of the B bitabove.</t> <t hangText="V:">Scalability structureabove.</dd> <dt>V:</dt> <dd>Scalability Structure (SS) data present. When set toone,1, theOPTIONAL<bcp14>OPTIONAL</bcp14> SS dataMUST<bcp14>MUST</bcp14> be present in the payload descriptor. Otherwise, the SS dataMUST NOT<bcp14>MUST NOT</bcp14> bepresent.</t> <t hangText="Z:">Notpresent.</dd> <dt>Z:</dt> <dd>Not a reference frame for upper spatial layers. If set to 1, indicates that frames with higher spatial layers SID+1 and greater of the current and following pictures do not depend on the currentspatial layerspatial-layer SID frame. This enables a decoderwhichthat is targeting a higher spatial layer to know that it can safely discard this packet's frame without processing it, without having to wait for the"D"D bit in the higher-layer frame (seebelow).</t> </list></t>below).</dd> </dl> <t>The mandatory first octet is followed by the extension data fields that areenabled:<list style="hanging"> <t hangText="M:">Theenabled:</t> <dl newline="false" spacing="normal"> <dt>M:</dt> <!-- [rfced] FYI: We've removed quotes from around certain bit names, e.g., ""D" bit" for consistency with similar uses in this document. Please let us know if this is not preferred. Please also see our cluster-wide question regarding bit names prior to reply. --> <dd>The most significant bit of the first octet is an extension flag. The fieldMUST<bcp14>MUST</bcp14> be present if the I bit is equal to one. If M is set, the PID fieldMUST<bcp14>MUST</bcp14> contain 15 bits; otherwise, itMUST<bcp14>MUST</bcp14> contain 7 bits. See PIDbelow.</t> <t hangText="Picturebelow.</dd> <dt>Picture ID(PID):">Picture(PID):</dt> <dd>Picture ID represented in 7 or 15 bits, depending on the M bit. This is a running index of the pictures, where the sender increments the value by 1 for each picture it sends.(Note however(Note, however, that because a middlebox can discard pictures where permitted by thescalability structure,SS, Picture IDs as received by a receiver might not be contiguous.) This fieldMUST<bcp14>MUST</bcp14> be present if the I bit is equal to one. If M is set tozero,0, 7 bits carry the PID;elseelse, if M is set toone,1, 15 bits carry the PID in network byte order. The sender may choose between a 7- or 15-bit index. The PIDSHOULD<bcp14>SHOULD</bcp14> start on a randomnumber,number andMUST<bcp14>MUST</bcp14> wrap after reaching the maximum ID (0x7f or 0x7fff depending on the index size chosen). The receiverMUST NOT<bcp14>MUST NOT</bcp14> assume that the number of bits in the PIDstaystays the same through the session. If this field transitions from7-bits7 bits to15-bits,15 bits, the value is zero-extended(i.e.(i.e., the value after 0x6e is 0x006f); if the field transitions from 15 bits to 7 bits, it is truncated(i.e.(i.e., the value after 0x1bbe is 0xbf).</t> <t>In</dd> <dt/> <dd>In the non-flexible mode (when the F bit is set to 0), this PID is used as an index to thepicture group (PG)PG specified in the SS data below. In this mode, the PID of thekey framekeyframe corresponds to the first specified frame in the PG. Then subsequent PIDs are mapped to subsequently specified frames in the PG (modulo N_G, specified in the SS data below),respectively.</t> <t>Allrespectively.</dd> <dt/> <dd>All frames of the same pictureMUST<bcp14>MUST</bcp14> have the same PIDvalue.</t> <t>Framesvalue.</dd> <dt/> <dd>Frames (and their corresponding pictures) with the VP9 show_frame field equal to 0MUST<bcp14>MUST</bcp14> have distinct PID values from subsequent pictures with show_frame equal to 1. Thus, aPicture aspicture (as defined in thisspecificationspecification) is different than a VP9Superframe.</t> <t>Allsuperframe.</dd> <dt/> <dd>All frames of the same pictureMUST<bcp14>MUST</bcp14> have the same value forshow_frame.</t> <t hangText="Layer indices:">Thisshow_frame.</dd> <!--[rfced] Might a clarification of "This information" be helpful to the reader? Original: Layer indices: This information is optional but RECOMMENDED whenever encoding with layers. Perhaps: Layer indices: This field is optional but RECOMMENDED whenever encoding with layers. --> <dt>Layer indices:</dt> <dd>This information is optional but <bcp14>RECOMMENDED</bcp14> whenever encoding with layers. For both flexible and non-flexible modes, one octet is used to specify a layer frame'stemporal layertemporal-layer ID (TID) andspatial layerspatial-layer ID (SID) as shown both in <xreftarget="figureVP9payloadDescriptor"/>target="figureVP9payloadDescriptor" format="default"/> and <xreftarget="figureVP9payloadDescriptorNonFlexible"/>.target="figureVP9payloadDescriptorNonFlexible" format="default"/>. Additionally, a bit (U) is used to indicate that the current frame is a "switching up point" frame. Another bit (D) is used to indicate whether inter-layer prediction is used for the currentframe.</t> <t>Inframe.</dd> <dt/> <dd>In the non-flexible mode (when the F bit is set to 0), another octet is used to representtemporal layertemporal-layer 0 index (TL0PICIDX), as depicted in <xreftarget="figureVP9payloadDescriptorNonFlexible"/>.target="figureVP9payloadDescriptorNonFlexible" format="default"/>. The TL0PICIDX is present so that all minimally required frames- the(the basetemporal layer frames -temporal-layer frames) can betracked.</t>tracked.</dd> <dt/> <dd> <t>The TID and SID fields indicate the temporal and spatial layers and can help middleboxes and endpoints quickly identify which layer a packet belongs to.<list style="hanging"> <t hangText="TID:">The temporal layer</t> <dl newline="false" spacing="normal"> <dt>TID:</dt> <dd>The temporal-layer ID of the current frame. In the case of non-flexible mode, if a PID is mapped to a picture in a specified PG, then the value of the TIDMUST<bcp14>MUST</bcp14> match the corresponding TID value of the mapped picture in thePG.</t> <t hangText="U:">Switching up point.PG.</dd> <dt>U:</dt> <!--[rfced] If TID expands to "temporal layer ID", does this text say "with TID equal to TID"? Please clarify. Original: If this bit is set to 1 for the current picture with temporal layer ID equal to TID... --> <dd>Switching up point. If this bit is set to 1 for the current picture with a temporal-layer ID equal to TID, then "switch up" to a higher frame rate is possible as subsequent highertemporal layertemporal-layer pictures will not depend on any picture before the current picture (in coding order) withtemporal layertemporal-layer ID greater thanTID.</t> <t hangText="SID:">The spatial layerTID.</dd> <dt>SID:</dt> <dd>The spatial-layer ID of the current frame. Note that frames withspatial layerspatial-layer SID > 0 may be dependent on decodedspatial layerspatial-layer SID-1 frame within the same picture. Different frames of the same pictureMUST<bcp14>MUST</bcp14> have distinctspatial layerspatial-layer IDs, and frames' spatial layersMUST<bcp14>MUST</bcp14> appear in increasing order within theframe.</t> <t hangText="D:">Inter-layerframe.</dd> <dt>D:</dt> <dd>Inter-layer dependency is used.MUSTD <bcp14>MUST</bcp14> be set toone1 if and only if the currentspatial layerspatial-layer SID frame depends onspatial layerspatial-layer SID-1 frame of the samepicture, otherwise MUSTpicture; otherwise, it <bcp14>MUST</bcp14> be set tozero.0. For thebase layerbase-layer frame (with SID equal to 0),thisthe D bitMUST<bcp14>MUST</bcp14> be set tozero.</t> <t hangText="TL0PICIDX:">80.</dd> <dt>TL0PICIDX:</dt> <dd>8 bitstemporal layertemporal-layer zero index. TL0PICIDX is only present in the non-flexible mode (F = 0). This is a running index for the temporalbase layerbase-layer pictures, i.e., the pictures with a TID set to 0. If the TID is larger than 0, TL0PICIDX indicates which temporalbase layerbase-layer picture the current picture depends on. TL0PICIDXMUST<bcp14>MUST</bcp14> be incremented by 1 when the TID is equal to 0. The indexSHOULD<bcp14>SHOULD</bcp14> start on a randomnumber,number andMUST<bcp14>MUST</bcp14> restart at 0 after reaching the maximum number255.</t> </list></t> <t hangText="Reference indices:">When255.</dd> </dl> </dd> <dt>Reference indices:</dt> <dd> <t>When P and F are both set toone,1, indicating anon-key framenon-keyframe in flexible mode, then at least one reference indexMUST<bcp14>MUST</bcp14> be specified as below. Additional reference indices(total(a total of up to3three reference indices are allowed) may be specified using the N bit below. When either P or F is set tozero,0, then no reference index is specified.<list style="hanging"> <t hangText="P_DIFF:">The</t> <dl newline="false" spacing="normal"> <dt>P_DIFF:</dt> <dd>The reference index (in 7 bits) specified as the relative PID from the current picture. For example, when P_DIFF=3 on a packet containing the picture with PID 112 means that the picture refers back to the picture with PID 109. This calculation is done modulo the size of the PID field, i.e., either 7 or 15 bits. A P_DIFF value of 0 isinvalid.</t> <t hangText="N:">1invalid.</dd> <dt>N:</dt> <dd>1 if there is additional P_DIFF following the currentP_DIFF.</t> </list></t> </list></t>P_DIFF.</dd> </dl> </dd> </dl> <section anchor="VP9payloadDescriptorSS"title="Scalabilitynumbered="true" toc="default"> <name>Scalability Structure(SS):">(SS)</name> <t>Thescalability structure (SS)SS data describes the resolution of each frame within a picture as well as the inter-picture dependencies for apicture group (PG).PG. If the VP9 payload descriptor's"V"V bit is set, the SS data is present in the position indicated in Figures <xref format="counter" target="figureVP9payloadDescriptor"/> and <xreftarget="figureVP9payloadDescriptorNonFlexible"/>.</t>target="figureVP9payloadDescriptorNonFlexible" format="counter"/>.</t> <figureanchor="figureVP9ScalabilityStructure"> <artwork><![CDATA[anchor="figureVP9ScalabilityStructure" title="VP9 Scalability Structure"> <artwork name="" type="" align="left" alt=""><![CDATA[ +-+-+-+-+-+-+-+-+ V: | N_S |Y|G|-|-|-| +-+-+-+-+-+-+-+-+ -\ Y: | WIDTH | (OPTIONAL) . + + . | | (OPTIONAL) . +-+-+-+-+-+-+-+-+ . - N_S + 1 times | HEIGHT | (OPTIONAL) . + + . | | (OPTIONAL) . +-+-+-+-+-+-+-+-+ -/ G: | N_G | (OPTIONAL) +-+-+-+-+-+-+-+-+ -\ N_G: | TID |U| R |-|-| (OPTIONAL) . +-+-+-+-+-+-+-+-+ -\ . - N_G times | P_DIFF | (OPTIONAL) . - R times . +-+-+-+-+-+-+-+-+ -/ -/ ]]></artwork> </figure><t><list style="hanging"> <t hangText="N_S:">N_S<!--[rfced] We note that not all fields that appear in Figure 4 are described following it. Please review and let us know if text (or a pointer to where the reader can get more information on these fields) should be added. --> <dl newline="false" spacing="normal"> <dt>N_S:</dt> <dd>N_S + 1 indicates the number of spatial layers present in the VP9stream.</t> <t hangText="Y:">Eachstream.</dd> <dt>Y:</dt> <dd>Each spatial layer's frame resolution is present. When set toone,1, theOPTIONAL<bcp14>OPTIONAL</bcp14> WIDTH (2 octets) and HEIGHT (2 octets)MUST<bcp14>MUST</bcp14> be present for each layer frame. Otherwise, the resolutionMUST NOT<bcp14>MUST NOT</bcp14> bepresent.</t> <t hangText="G:">PGpresent.</dd> <dt>G:</dt> <dd>The PG description presentflag.</t> <t hangText="-:">Bitflag.</dd> <dt>-:</dt> <dd>A bit reserved for future use.MUSTIt <bcp14>MUST</bcp14> be set tozero0 andMUST<bcp14>MUST</bcp14> be ignored by thereceiver.</t> <t hangText="N_G:">N_Greceiver.</dd> <dt>N_G:</dt> <dd>N_G indicates the number of pictures in aPicture Group (PG).PG. If N_G is greater than 0, then the SS data allows the inter-picture dependency structure of the VP9 stream to be pre-declared, rather than indicating it on the fly with every packet. If N_G is greater than 0, then for N_G pictures in the PG, each picture'stemporal layertemporal-layer ID (TID), switch up point (U), andtheReference indices (P_DIFFs) arespecified.</t> <t>Thespecified.</dd> <dt/> <dd>The first picture specified in the PGMUST<bcp14>MUST</bcp14> have a TID set to0.</t> <t>G0.</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 thebitstream.</t> <t>Notebitstream.</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 eachother andother; this can be described with the use of the D bit described above. The specified dependency structure in the SS dataMUST<bcp14>MUST</bcp14> be for the highest frame ratelayer.</t> </list></t>layer.</dd> </dl> <t>In a scalable stream sent with a fixed pattern, the SS dataSHOULD<bcp14>SHOULD</bcp14> be included in the first packet of every key frame. This is a packet with the P bit equal tozero,0, SID or L bit equal tozero,0, and B bit equal to 1. The SS dataMUST<bcp14>MUST</bcp14> only be changed on the picture that corresponds to the first picture specified in the previous SS data's PG (if the previous SS data's N_G was greater than 0).</t> </section> </section> <sectiontitle="Frame Fragmentation">numbered="true" toc="default"> <name>Frame Fragmentation</name> <t>VP9 frames are fragmented intopackets,packets in RTP sequence numberorder,order: beginning with a packet with the B bitset,set and ending with a packet with the E bit set. There is no mechanism for finer-grained access to parts of a VP9 frame.</t> </section> <sectiontitle="Scalable encoding considerations">numbered="true" toc="default"> <name>Scalable Encoding Considerations</name> <t>In addition to the use of reference frames, VP9 has several additional forms of inter-frame dependencies, largely involving probability tables for the entropy and tree encoders. In VP9 syntax, the syntax element "error_resilient_mode" resets this additional inter-frame data, allowing a frame's syntax to be decoded independently.</t> <t>Due to the requirements of scalable streams, a VP9 encoder producing a scalable stream needs to ensure that a frame does not depend on a previous frame (of the same or a previous picture) that can legitimately be removed from the stream. Thus, a frame that follows a frame that might be removed (in full decode order)MUST<bcp14>MUST</bcp14> be encoded with "error_resilient_mode" set to true.</t> <t>Forspatially-scalablespatially scalable streams, this means that "error_resilient_mode" needs to be turned on for the base spatial layer; however, it canhoweverbe turned off for higher spatial layers, assuming they are sent with inter-layer dependency(i.e.(i.e., with the"D"D bit set). For streams that are onlytemporally-scalabletemporally scalable without spatial scalability, "error_resilient_mode" can additionally be turned off for any picture that immediately follows atemporal layertemporal-layer 0 frame.</t> </section> <sectiontitle="Examplesnumbered="true" toc="default"> <name>Examples of VP9 RTPStream">Stream</name> <sectiontitle="Reference picture usenumbered="true" toc="default"> <name>Reference Picture Use forscalable structure">Scalable Structure</name> <t>As discussed in <xreftarget="mediaFormatDescription"/>,target="mediaFormatDescription" format="default"/>, the VP9 codec can maintain up to eight reference frames, of which up to three can be referenced or updated by any new frame. This section illustrates one way that a scalable structure (with three spatial layers and three temporal layers) can be constructed using these reference frames.</t><texttable title="Example scalability structure"> <ttcol align="center">Temporal</ttcol> <ttcol align="center">Spatial</ttcol> <ttcol align="center">References</ttcol> <ttcol align="center">Updates</ttcol> <c>0</c><c>0</c><c>0</c><c>0</c> <c>0</c><c>1</c><c>0,1</c><c>1</c> <c>0</c><c>2</c><c>1,2</c><c>2</c> <c>2</c><c>0</c><c>0</c><c>6</c> <c>2</c><c>1</c><c>1,6</c><c>7</c> <c>2</c><c>2</c><c>2,7</c><c>-</c> <c>1</c><c>0</c><c>0</c><c>3</c> <c>1</c><c>1</c><c>1,3</c><c>4</c> <c>1</c><c>2</c><c>2,4</c><c>5</c> <c>2</c><c>0</c><c>3</c><c>6</c> <c>2</c><c>1</c><c>4,6</c><c>7</c> <c>2</c><c>2</c><c>5,7</c><c>-</c> </texttable><table align="center"> <name>Example Scalability Structure</name> <thead> <tr> <th align="center">Temporal</th> <th align="center">Spatial</th> <th align="center">References</th> <th align="center">Updates</th> </tr> </thead> <tbody> <tr> <td align="center">0</td> <td align="center">0</td> <td align="center">0</td> <td align="center">0</td> </tr> <tr> <td align="center">0</td> <td align="center">1</td> <td align="center">0,1</td> <td align="center">1</td> </tr> <tr> <td align="center">0</td> <td align="center">2</td> <td align="center">1,2</td> <td align="center">2</td> </tr> <tr> <td align="center">2</td> <td align="center">0</td> <td align="center">0</td> <td align="center">6</td> </tr> <tr> <td align="center">2</td> <td align="center">1</td> <td align="center">1,6</td> <td align="center">7</td> </tr> <tr> <td align="center">2</td> <td align="center">2</td> <td align="center">2,7</td> <td align="center">-</td> </tr> <tr> <td align="center">1</td> <td align="center">0</td> <td align="center">0</td> <td align="center">3</td> </tr> <tr> <td align="center">1</td> <td align="center">1</td> <td align="center">1,3</td> <td align="center">4</td> </tr> <tr> <td align="center">1</td> <td align="center">2</td> <td align="center">2,4</td> <td align="center">5</td> </tr> <tr> <td align="center">2</td> <td align="center">0</td> <td align="center">3</td> <td align="center">6</td> </tr> <tr> <td align="center">2</td> <td align="center">1</td> <td align="center">4,6</td> <td align="center">7</td> </tr> <tr> <td align="center">2</td> <td align="center">2</td> <td align="center">5,7</td> <td align="center">-</td> </tr> </tbody> </table> <t>This structure is constructed such that the"U"U bit can always be set.</t> </section> </section> </section> <section anchor="Feedback"title="Feedbacknumbered="true" toc="default"> <name>Feedback Messages and HeaderExtensions">Extensions</name> <section anchor="RPSI"title="Referencenumbered="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)">(RPSI)</name> <t>The reference picture selection index is a payload-specific feedback message defined within the RTCP-based feedback format. The RPSI message is generated by a receiver and can be used in twoways. Eitherways: either it can signal a preferred reference picture when a loss has been detected by the decoder-- preferably then(preferably a reference that the decoder knows isperfect -- or,perfect) or it can be used as positive feedback information to acknowledge correct decoding of certain reference pictures. The positive feedback method is useful for VP9 used forpoint to pointpoint-to-point (unicast) communication. The use of RPSI for VP9 is preferably combined with a special update pattern of the codec's two special reference frames -- the golden frame and the altref frame -- in which they are updated in an alternating leapfrog fashion. When a receiver has received and correctly decoded a golden or altref frame, and that frame had a Picture ID in the payload descriptor, the receiver can acknowledge this simply by sending an RPSI message back to the sender. The message body (i.e., the "native RPSI bit string" in <xreftarget="RFC4585"/>)target="RFC4585" format="default"/>) is simply the(7(7- or15 bit)15-bit) Picture ID of the received frame.</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://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 message to specify which frame is being selected.</t> </section> <sectiontitle='Fullanchor="FIR" numbered="true" toc="default"> <name>Full Intra Request(FIR)' anchor="FIR">(FIR)</name> <t>The <xreftarget='RFC5104'>Fulltarget="RFC5104" format="default">Full Intra Request (FIR)</xref> RTCP feedback message allows a receiver to request a full state refresh of an encoded stream.</t> <t>Upon receipt ofana FIR request, a VP9 senderMUST<bcp14>MUST</bcp14> send a picture with a keyframe for itsspatial layerspatial-layer 0 layerframe,frame and then send frames without inter-picture prediction (P=0) for anyhigher layerhigher-layer frames.</t> </section> <sectiontitle="Layeranchor="LRR" numbered="true" toc="default"> <name>Layer Refresh Request(LRR)" anchor="LRR">(LRR)</name> <t>The <xreftarget="I-D.ietf-avtext-lrr">Layertarget="RFC9627" format="default">Layer Refresh Request (LRR)</xref> allows a receiver to request a single layer of a spatially or temporally encoded stream to berefreshed,refreshed without necessarily affecting the stream's other layers.</t> <figureanchor="figureLRRIndexFormat"> <artwork><![CDATA[anchor="figureLRRIndexFormat" title="LRR Index Format"> <artwork name="" type="" align="left" alt=""><![CDATA[ +---------------+---------------+ |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| +---------------+---------+-----+ | RES | TID | RES | SID | +---------------+---------+-----+ ]]></artwork> </figure> <t><xreftarget="figureLRRIndexFormat"/>target="figureLRRIndexFormat" format="default"/> shows the format of an LRR's layer index fields for VP9 streams. The two "RES" fieldsMUST<bcp14>MUST</bcp14> be set to 0 on transmission andingnoredignored on reception. See <xreftarget="VP9payloadDescriptor"/>target="VP9payloadDescriptor" format="default"/> for details on the TID and SID fields.</t> <!-- [rfced] In the following sentences: a) does the receiver want to upgrade to {2,1}? How might we clarify "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.ThereforeTherefore, it's recommended for both the flexible and the non-flexible mode that, when switching up points are being encoded in response toaan LRR, those packetsshouldcontain layer indices and the referencefield(s)field or fields so that the decoder ora<xreftarget='RFC7667'>selectivetarget="RFC7667" format="default">selective forwarding middleboxes</xref> can make this derivation.</t> <t>Example:</t> <t>LRR {1,0}, {2,1} is sent byan MCUa Multipoint Control Unit (MCU) when it is currently relaying {1,0} to a receiver and which wants to upgrade to {2,1}. Inresponseresponse, the encoder should encode the next frames in layers {1,1} and {2,1} by only referring to frames in {1,0}, or {0,0}.</t> <t>In the non-flexible mode, periodic upgrade frames can be defined by the layer structure of theSS, thusSS; thus, periodic upgrade frames can be automatically identified by thepicturePicture ID.</t> </section> </section> <section anchor="payloadFormatParameters"title="Payloadnumbered="true" toc="default"> <!--[rfced] In the following, please review the use of "value" (singular) and "receivers" (not possessive?). Original: ...where a media sender does not have media available that fits within a receivers max-fs and max-fr value;... Perhaps: ...where a media sender does not have media available that fits within a receiver's max-fs and max-fr values;... --> <name>Payload FormatParameters">Parameters</name> <t>This payload format has three optionalparameters, "max-fr", "max-fs",parameters: max-fr, max-fs, and"profile-id".</t>profile-id.</t> <t>The max-fr and max-fs parameters are used to signal the capabilities of a receiver implementation. If the implementation is willing to receive media, both parametersMUST<bcp14>MUST</bcp14> be provided. These parametersMUST NOT<bcp14>MUST NOT</bcp14> be used for any other purpose. A media senderSHOULD NOT<bcp14>SHOULD NOT</bcp14> send media with a frame rate or frame size exceeding the max-fr and max-fs values signaled. (There may be scenarios, such as pre-encoded media or <xreftarget='RFC7667'>selectivetarget="RFC7667" format="default">selective forwarding middleboxes</xref>, where a media sender does not have media available that fits within areceiversreceiver's max-fs and max-fr value; in such scenarios, a senderMAY<bcp14>MAY</bcp14> exceed the signaled values.)<list style="hanging"> <t hangText="max-fr:">The</t> <dl newline="false" spacing="normal"> <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 ofdecoding.</t> <t hangText="max-fs:">Thedecoding.</dd> <dt>max-fs:</dt> <dd>The value of max-fs is an integer indicating the maximum frame size in units of macroblocks that the decoder is capable ofdecoding.</t> <t>Thedecoding.</dd> <dt/> <!--[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 than int(sqrt(max-fs * 8)); for instance, a max-fs of 1200 (capable of supporting 640x480 resolution) will support widths and heights up to 1552 pixels (97macroblocks).</t> <t hangText="profile-id:">Themacroblocks).</dd> <dt>profile-id:</dt> <dd>The value of profile-id is an integer indicating the default codingprofile, theprofile (the subset of coding tools that may have been used to generate the stream or that the receiver supports). <xreftarget="TableOfProfileIds"/>target="TableOfProfileIds" format="default"/> lists all of the profiles defined insectionSection 7.2 of <xreftarget="VP9-BITSTREAM"/>target="VP9-BITSTREAM" format="default"/> and the corresponding integer values to beused.</t> <t>Ifused.</dd> <dt/> <dd>If no profile-id is present, Profile 0MUST<bcp14>MUST</bcp14> be inferred. (The profile-id parameter was added relatively late in the development of this specification, so some existing implementations may not send it.)</t> <t>Informative</dd> <dt/> <dd>Informative note: See <xreftarget="TableOfProfiles"/>target="TableOfProfiles" format="default"/> for capabilities of coding profiles defined insectionSection 7.2 of <xreftarget="VP9-BITSTREAM"/>.</t> </list></t>target="VP9-BITSTREAM" format="default"/>.</dd> </dl> <t>A receiverMUST<bcp14>MUST</bcp14> ignore any parameter unspecified in this specification.</t><texttable anchor="TableOfProfileIds" title="Table<!--[rfced] Please note that we have shortened the title of Table 2 and rephrased to avoid awkward hyphenation. Please review and let us know any objections. Original: Table of profile-id integer values representing theVP9VP( profile corresponding to the set of coding toolssupported."> <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="Tablesupported Current: profile-id to VP9 Profile Integer Comparison Current: Comparison ofprofile capabilities."> <ttcol align="center">Profile</ttcol> <ttcolprofile-id to VP9 Profile Integer --> <table anchor="TableOfProfileIds" align="center"> <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">BitDepth</ttcol> <ttcolDepth</th> <th align="center">SRGBColorspace</ttcol> <ttcolColorspace</th> <th align="center">ChromaSubsampling</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>YUVSubsampling</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 or4:4:4</c> <c>2</c><c>104:4:4</td> </tr> <tr> <td align="center">2</td> <td align="center">10 or12</c><c>No</c><c>YUV 4:2:0</c> <c>3</c><c>1012</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 or12</c><c>Yes</c><c>YUV12</td> <td align="center">Yes</td> <td align="center">YUV 4:2:2,4:4:0 or4:4:4</c> </texttable>4:4:4</td> </tr> </tbody> </table> <section anchor="SDPParameters"title="SDP Parameters">numbered="true" toc="default"> <name>SDP Parameters</name> <sectiontitle="Mappingnumbered="true" toc="default"> <name>Mapping of Media Subtype Parameters toSDP">SDP</name> <t>The media typevideo/VP9video/vp9 string is mapped to fields in the Session Description Protocol (SDP) <xreftarget="RFC8866"/>target="RFC8866" format="default"/> as follows:<list style="symbols"> <t>The</t> <ul spacing="normal"> <li>The media name in the "m=" line of SDPMUST<bcp14>MUST</bcp14> bevideo.</t> <t>Thevideo.</li> <li>The encoding name in the "a=rtpmap" line of SDPMUST<bcp14>MUST</bcp14> be VP9 (the mediasubtype).</t> <t>Thesubtype).</li> <li>The clock rate in the "a=rtpmap" lineMUST<bcp14>MUST</bcp14> be90000.</t> <t>The90000.</li> <li>The parameters"max-fr"max-fr and"max-fs" MUSTmax-fs <bcp14>MUST</bcp14> be included in the "a=fmtp" line of SDP if the receiver wishes to declare its receiver capabilities. These parameters are expressed as a media subtypestring,string in the form of asemicolon separatedsemicolon-separated list of parameter=valuepairs.</t> <t>The OPTIONALpairs.</li> <li>The <bcp14>OPTIONAL</bcp14> parameter profile-id, when present,SHOULD<bcp14>SHOULD</bcp14> be included in the "a=fmtp" line of SDP. This parameter is expressed as a media subtypestring,string in the form of a parameter=value pair. When the parameter is not present, a value of 0MUST<bcp14>MUST</bcp14> be inferred forprofile-id.</t> </list></t>profile-id.</li> </ul> <sectiontitle="Example">numbered="true" toc="default"> <name>Example</name> <t>An example of media representation in SDP is as follows:</t><figure> <artwork>m=video<sourcecode type="sdp"><![CDATA[m=video 49170 RTP/AVPF 98 a=rtpmap:98 VP9/90000 a=fmtp:98 max-fr=30;max-fs=3600;profile-id=0</artwork> </figure>]]></sourcecode> </section> </section> <sectiontitle="Offer/Answer Considerations">numbered="true" toc="default"> <name>Offer/Answer Considerations</name> <t>When VP9 is offered over RTP using SDP in an Offer/Answer model <xreftarget="RFC3264"/>target="RFC3264" format="default"/> for negotiation for unicast usage, the following limitations and rules apply:<list style="symbols"> <t>The</t> <ul spacing="normal"> <li>The parameter identifying a media format configuration for VP9 is profile-id. This media format configuration parameterMUST<bcp14>MUST</bcp14> be used symmetrically; that is, the answererMUST<bcp14>MUST</bcp14> either maintain this configuration parameter or remove the media format (payload type) completely if it is notsupported.</t> <t>Thesupported.</li> <li>The max-fr and max-fs parameters are used declaratively to describe receiver capabilities, even in the Offer/Answer model. The values in an answer are used to describe the answerer'scapabilities, and thuscapabilities; thus, their values are set independently of the values in theoffer.</t> <t>Tooffer.</li> <li>To simplify the handling and matching of these configurations, the same RTP payload type number used in the offerSHOULD<bcp14>SHOULD</bcp14> also be used in the answer and in a subsequent offer, as specified in <xreftarget="RFC3264"/>.target="RFC3264" format="default"/>. An answer or subsequent offerMUST NOT<bcp14>MUST NOT</bcp14> contain the payload type number used in the offer unless the profile-id value is exactly the same as in the original offer. However, max-fr and max-fs parametersMAY<bcp14>MAY</bcp14> be changed in subsequent offers and answers, with the same payload type number, if an endpoint wishes to change its declared receivercapabilities.</t> </list></t>capabilities.</li> </ul> </section> </section> </section> <section anchor="mediaTypeRegistration"title="Medianumbered="true" toc="default"> <name>Media TypeDefinition">Definition</name> <t>This registrationis done usinguses the template defined in <xreftarget="RFC6838"/>target="RFC6838" format="default"/> and following <xreftarget="RFC4855"/>. <list style="hanging"> <t hangText="Type name:">video</t> <t hangText="Subtype name:">VP9</t> <t hangText="Required parameters:">N/A.</t> <t hangText="Optional parameters:"><vspace blankLines="0"/>target="RFC4855" format="default"/>. </t> <!--[rfced] Please note that after AUTH48 concludes, we will communicate any changes to the media type template in Section 7 to IANA for corresponding updates to https://www.iana.org/assignments/media-types/video/VP9 to be made.--> <dl newline="false" spacing="normal"> <dt>Type name:</dt> <dd>video</dd> <dt>Subtype name:</dt> <dd>VP9</dd> <dt>Required parameters:</dt> <dd>N/A</dd> <dt>Optional parameters:</dt> <dd> There are three optionalparameters, "max-fr", "max-fs",parameters: max-fr, max-fs, and"profile-id".profile-id. See <xreftarget='payloadFormatParameters' />target="payloadFormatParameters" format="default"/> for their definition.</t> <t hangText="Encoding considerations:"><vspace blankLines="0"/></dd> <dt>Encoding considerations:</dt> <dd> This media type is framed in RTP and contains binary data; seeSection 4.8 of<xreftarget="RFC6838"/>.</t> <t hangText="Security considerations:">Seetarget="RFC6838" sectionFormat="of" section="4.8" format="default"/>.</dd> <dt>Security considerations:</dt> <dd> <t>See <xreftarget="securityConsiderations"/>target="securityConsiderations" format="default"/> of RFCxxxx. <vspace blankLines="0"/> [RFC Editor: Upon publication as an RFC, please replace "XXXX" with the number assigned to this document and remove this note.]</t> <t hangText="Interoperability considerations:">None.</t> <t hangText="Published specification:">VP99628. </t> </dd> <dt>Interoperability considerations:</dt> <dd>None</dd> <dt>Published specification:</dt> <dd> <t>VP9 bitstream format <xreftarget="VP9-BITSTREAM"/>target="VP9-BITSTREAM" format="default"/> and RFCXXXX. <vspace blankLines="0"/> [RFC Editor: Upon publication as an RFC, please replace "XXXX" with the number assigned to this document and remove this note.] <vspace blankLines="0"/></t> <t hangText="Applications which9628. </t> </dd> <dt>Applications that use this mediatype:"><vspace blankLines="0"/>type:</dt> <dd> Forexample: Videoexample, video over IP, videoconferencing.</t> <t hangText="Fragmentconferencing.</dd> <dt>Fragment identifierconsiderations:">N/A.</t> <t hangText="Additional information:">None.</t> <t hangText="Personconsiderations:</dt> <dd>N/A</dd> <dt>Additional information:</dt> <dd>None</dd> <dt>Person & email address to contact for furtherinformation:"><vspace blankLines="0"/> Jonathan Lennox <jonathan.lennox@8x8.com></t> <t hangText="Intended usage:">COMMON</t> <t hangText="Restrictionsinformation:</dt> <dd><t><contact fullname="Jonathan Lennox"/> <jonathan.lennox@8x8.com></t></dd> <dt>Intended usage:</dt> <dd>COMMON</dd> <dt>Restrictions onusage:"><vspace blankLines="0"/>usage:</dt> <dd> This media type depends on RTPframing, and henceframing; hence, it is only defined for transfer via RTP <xreftarget="RFC3550"/>.</t> <t hangText="Author:">Jonathan Lennox <jonathan.lennox@8x8.com></t> <t hangText="Change controller:"><vspace blankLines="0"/>target="RFC3550" format="default"/>.</dd> <dt>Author:</dt> <dd><t><contact fullname="Jonathan Lennox"/> <jonathan.lennox@8x8.com></t></dd> <!--[rfced] Please review the entry for "Change Controller" in Section 7. While we see similar text for the vp8 and vc2 entries, we want to confirm that this entry has been reviewed with the following in mind from https://www.iana.org/help/protocol-registration: "The IESG shouldn't be listed as a change controller unless the RFC that created the registry (e.g. port numbers, XML namespaces and schemas) requires it. The IETF should be named instead." --> <dt>Change controller:</dt> <dd> IETF AVTCore Working Group delegated from theIESG.</t> </list></t>IESG.</dd> </dl> </section> <section anchor="securityConsiderations"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification <xreftarget="RFC3550"/>,target="RFC3550" format="default"/>, and in any applicable RTP profile such as <xreftarget='RFC3551'>RTP/AVP</xref>,target="RFC3551" format="default">RTP/AVP</xref>, <xreftarget='RFC4585'>RTP/AVPF</xref>,target="RFC4585" format="default">RTP/AVPF</xref>, <xreftarget='RFC3711'>RTP/SAVP</xref>,target="RFC3711" format="default">RTP/SAVP</xref>, or <xreftarget='RFC5124'>RTP/SAVPF</xref>.target="RFC5124" format="default">RTP/SAVPF</xref>. However, as "<xref target="RFC7202" format="title"/>" <xreftarget='RFC7202'>"Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution"</xref>target="RFC7202" format="default"></xref> discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality,integrityintegrity, and source authenticity for RTP in general. This responsibilitylays onlies with anyone using RTP in an application. They can find guidance on available security mechanisms in "<xref target="RFC7201" format="title"/> <xreftarget='RFC7201'>Options for Securing RTP Sessions</xref>.target="RFC7201" format="default"></xref>. ApplicationsSHOULD<bcp14>SHOULD</bcp14> use one or more appropriate strong securitymechanisms. The rest of this security consideration section discusses the security impacting properties of the payload format itself.</t>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 otherwisemis-behave.misbehave. An overrun in allocated memory could lead to arbitrary code execution by an attacker. The same applies to the encoder, even though problems in encoders aretypically(typically) rarer.</t> <t>This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packetprocessing, and thusprocessing; thus, they are unlikely to pose a denial-of-service threat due to the receipt of pathological data. Nor does the RTP payload format contain any active content.</t> </section> <section anchor="congestionControl"title="Congestion Control">numbered="true" toc="default"> <name>Congestion Control</name> <t>Congestion control for RTPSHALL<bcp14>SHALL</bcp14> be used in accordance withRFC 3550<xreftarget="RFC3550"/>,target="RFC3550" format="default"/>, and with any applicable RTPprofile;profile, e.g.,RFC 3551<xreftarget="RFC3551"/>.target="RFC3551" format="default"/>. The congestion control mechanism can, in a real-time encoding scenario, adapt the transmission rate by instructing the encoder to encode at a certain target rate.Media awareMedia-aware network elementsMAY<bcp14>MAY</bcp14> use the information in the VP9 payload descriptor in <xreftarget="VP9payloadDescriptor"/>target="VP9payloadDescriptor" format="default"/> to identify non-reference frames and discard them in order to reduce network congestion. Note that discarding of non-reference frames cannot be done if the stream is encrypted (because the non-reference marker is encrypted).</t> </section> <section anchor="IANAConsiderations"title="IANA Considerations"> <t>Thenumbered="true" toc="default"> <name>IANA Considerations</name> <!--[rfced] Should any further information on the IANAis requestedConsiderations for the "RTP Payload Format Media Types" registry be given? Perhaps: The media type has also been added toregisterthe "RTP Payload Format Media Types" subregistry of th e"Real-Time Transport Protocol (RTP) Parameters" registry as follows: Media Type: video Subtype: VP9 Clock Rate (Hz): 90000 Reference: RFC 9628 --> <t>IANA has registered the media type registration "video/vp9" as specified in <xreftarget="mediaTypeRegistration"/>.target="mediaTypeRegistration" format="default"/>. The media typeishas alsorequested to bebeen added to theIANA registry for"RTP Payload FormatMIME types" <http://www.iana.org/assignments/rtp-parameters>.</t> </section> <section title="Acknowledgments"> <t>Alex Eleftheriadis, Yuki Ito, Won Kap Jang, Sergio Garcia Murillo, Roi Sasson, Timothy Terriberry, Emircan Uysaler, and Thomas Volkert commented on the developmentMedia Types" <eref target="https://www.iana.org/assignments/rtp-parameters" brackets="angle"/> subregistry ofthis document and provided helpful comments and feedback.</t>the "Real-Time Transport Protocol (RTP) Paramaeters" registry.</t> </section> </middle> <back><references title='Normative References'><references> <name>References</name> <references> <name>Normative References</name> <referenceanchor='VP9-BITSTREAM' target='https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf'>anchor="VP9-BITSTREAM" target="https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf"> <front> <title>VP9 Bitstream & Decoding Process Specification</title> <authorinitials='A' surname='Grange' fullname='Adrian Grange'>initials="A" surname="Grange" fullname="Adrian Grange"> <organization>Google</organization> </author> <authorinitials='P' surname='de Rivaz' fullname='Peterinitials="P" surname="de Rivaz" fullname="Peter deRivaz'>Rivaz"> <organization>Argon Design</organization> </author> <authorinitials='J' surname='Hunt' fullname='Jonathan Hunt'>initials="J" surname="Hunt" fullname="Jonathan Hunt"> <organization>Argon Design</organization> </author> <datemonth='March' day='31' year='2016' />month="March" day="31" year="2016"/> <abstract> <t> This document defines the bitstream format and decoding process for the Google VP9 video codec. </t> </abstract> </front> <seriesInfoname='Version' value='0.6'name="Version" value="0.6"/> </reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8866.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4855.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5104.xml"/> <!-- [I-D.ietf-avtext-lrr] companion document RFC 9627 --> <reference anchor="RFC9627" target="https://www.rfc-editor.org/info/rfc9627"> <front> <title>The Layer Refresh Request (LRR) RTCP Feedback Message</title> <author initials="J." surname="Lennox" fullname="Jonathan Lennox"> <organization>Vidyo, Inc.</organization> </author> <author initials="D." surname="Hong" fullname="Danny Hong"> <organization>Vidyo, Inc.</organization> </author> <author initials="J." surname="Uberti" fullname="Justin Uberti"> <organization>Google, Inc.</organization> </author> <author initials="S." surname="Holmer" fullname="Stefan Holmer"> <organization>Google, Inc.</organization> </author> <author initials="M." surname="Flodman" fullname="Magnus Flodman"> <organization>Google, Inc.</organization> </author> <date month="August" year="2024" /> </front> <seriesInfo name="RFC" value="9627" /> <seriesInfo name="DOI" value="10.17487/RFC9627"/> </reference>&rfc2119; &rfc8174; &rfc4585; &rfc3550; &rfc8866; &rfc6838; &rfc4855; &rfc5104; &lrr; &rfc3264;<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/> </references><references title='Informative References'> &rfc3551; &rfc5124; &rfc6386; &rfc7201; &rfc7202; &rfc7667; &rfc3711;<references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3551.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5124.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6386.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7201.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7202.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7667.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml"/> </references></back> </rfc></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> <!--LocalWords: PictureID DCT Hadamard WHT SSRC CSRC pyld hdr FI VER RPSI[rfced] Terminology and abbreviations: We had the following questions related to terminology or abbreviation use throughout the document. a) The following terms had different forms throughout this document. Please let us know if/how these may be made uniform. reference indices vs. Reference Indices b) We have updated these terms to be the form on the right to match use in the companion documents and/or be consistent within this document. key frame vs. keyframe "max-fs" vs. max-fs "max-fr" vs. max-fr "profile-id" vs. profile-id c) How may we expand "SRGB"? Segment Routing Global Block? If so, would you like to add as a note to the table? Or is this something that could be housed in the Terminology section? d) Is SID expanded to spatial-layer ID? It seems so here: Original: ...temporal-layer ID (TID) and spatial layer ID (SID)... 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: Original: Within a picture, a frame with spatial layer ID equal to SID... 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). 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. Original: TL0PICIDX: 8 bits temporal-layer zero index. and ...is used to represent temporal layer 0 index (TL0PICIDX)... Further, may we update to either "8-bit" or rephrase to put this information in parentheses (as was done in RFC 9626)? f) Is N_S an abbreviation for "Number of Spatial layers"? Might the explanation in Section 4.2.1 be made clearer? Original: N_S: N_S + 1 indicates the number of spatial layers present in the VP9 stream. Perhaps: N_S: Number of Spatial layers. N_S + 1 indicates the number of spatial layers present in the VP9 stream. g) Please note that we have expanded these abbreviations as follows. Please let us know any objections. MCU - Multipoint Control Unit (per RFC 5104) --> <!--LocalWords: stPartitionSize SDP AVPF SRTP IANA PID PICIDX TID[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. We see the use of "native" but note that it is a quote from RFC 4585. 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-author-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. --> </back> </rfc>