idnits 2.17.1 draft-ietf-avtext-lrr-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2017) is 2487 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-avtext-framemarking-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-avtext-framemarking (ref. 'I-D.ietf-avtext-framemarking') == Outdated reference: A later version (-16) exists of draft-ietf-payload-vp9-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Payload Working Group J. Lennox 3 Internet-Draft D. Hong 4 Intended status: Standards Track Vidyo 5 Expires: December 31, 2017 J. Uberti 6 S. Holmer 7 M. Flodman 8 Google 9 June 29, 2017 11 The Layer Refresh Request (LRR) RTCP Feedback Message 12 draft-ietf-avtext-lrr-07 14 Abstract 16 This memo describes the RTCP Payload-Specific Feedback Message "Layer 17 Refresh Request" (LRR), which can be used to request a state refresh 18 of one or more substreams of a layered media stream. It also defines 19 its use with several RTP payloads for scalable media formats. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 31, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 2 57 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Layer Refresh Request . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6 60 3.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4. Usage with specific codecs . . . . . . . . . . . . . . . . . 8 62 4.1. H264 SVC . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.2. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4.3. H265 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5. Usage with different scalability transmission mechanisms . . 11 66 6. SDP Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 9.2. Informative References . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 This memo describes an RTCP [RFC3550] Payload-Specific Feedback 77 Message [RFC4585] "Layer Refresh Request" (LRR). It is designed to 78 allow a receiver of a layered media stream to request that one or 79 more of its substreams be refreshed, such that it can then be decoded 80 by an endpoint which previously was not receiving those layers, 81 without requiring that the entire stream be refreshed (as it would be 82 if the receiver sent a Full Intra Request (FIR); [RFC5104] see also 83 [RFC8082]). 85 The feedback message is applicable both to temporally and spatially 86 scaled streams, and to both single-stream and multi-stream 87 scalability modes. 89 2. Conventions, Definitions and Acronyms 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2.1. Terminology 97 A "Layer Refresh Point" is a point in a scalable stream after which a 98 decoder, which previously had been able to decode only some (possibly 99 none) of the available layers of stream, is able to decode a greater 100 number of the layers. 102 For spatial (or quality) layers, in normal encoding, a subpicture can 103 depend both on earlier pictures of that spatial layer and also on 104 lower-layer pictures of the current picture. A layer refresh, 105 however, typically requires that a spatial layer picture be encoded 106 in a way that references only the lower-layer subpictures of the 107 current picture, not any earlier pictures of that spatial layer. 108 Additionally, the encoder must promise that no earlier pictures of 109 that spatial layer will be used as reference in the future. 111 However, even in a layer refresh, layers other than the ones being 112 refreshed may still maintain dependency on earlier content of the 113 stream. This is the difference between a layer refresh and a Full 114 Intra Request [RFC5104]. This minimizes the coding overhead of 115 refresh to only those parts of the stream that actually need to be 116 refreshed at any given time. 118 An illustration of spatial layer refresh of an enhancement layer is 119 shown below. <-- indicates a coding dependency. 121 ... <-- S1 <-- S1 S1 <-- S1 <-- ... 122 | | | | 123 \/ \/ \/ \/ 124 ... <-- S0 <-- S0 <-- S0 <-- S0 <-- ... 126 1 2 3 4 128 Figure 1 130 In Figure 1, frame 3 is a layer refresh point for spatial layer S1; a 131 decoder which had previously only been decoding spatial layer S0 132 would be able to decode layer S1 starting at frame 3. 134 An illustration of spatial layer refresh of a base layer is shown 135 below. <-- indicates a coding dependency. 137 ... <-- S1 <-- S1 <-- S1 <-- S1 <-- ... 138 | | | | 139 \/ \/ \/ \/ 140 ... <-- S0 <-- S0 S0 <-- S0 <-- ... 142 1 2 3 4 144 Figure 2 146 In Figure 2, frame 3 is a layer refresh point for spatial layer S0; a 147 decoder which had previously not been decoding the stream at all 148 could decode layer S0 starting at frame 3. 150 For temporal layers, while normal encoding allows frames to depend on 151 earlier frames of the same temporal layer, layer refresh requires 152 that the layer be "temporally nested", i.e. use as reference only 153 earlier frames of a lower temporal layer, not any earlier frames of 154 this temporal layer, and also promise that no future frames of this 155 temporal layer will reference frames of this temporal layer before 156 the refresh point. In many cases, the temporal structure of the 157 stream will mean that all frames are temporally nested, in which case 158 decoders will have no need to send LRR messages for the stream. 160 An illustration of temporal layer refresh is shown below. <-- 161 indicates a coding dependency. 163 ... <----- T1 <------ T1 T1 <------ ... 164 / / / 165 |_ |_ |_ 166 ... <-- T0 <------ T0 <------ T0 <------ T0 <--- ... 168 1 2 3 4 5 6 7 170 Figure 3 172 In Figure 3, frame 6 is a layer refresh point for temporal layer T1; 173 a decoder which had previously only been decoding temporal layer T0 174 would be able to decode layer T1 starting at frame 6. 176 An illustration of an inherently temporally nested stream is shown 177 below. <-- indicates a coding dependency. 179 T1 T1 T1 180 / / / 181 |_ |_ |_ 182 ... <-- T0 <------ T0 <------ T0 <------ T0 <--- ... 184 1 2 3 4 5 6 7 186 Figure 4 188 In Figure 4, the stream is temporally nested in its ordinary 189 structure; a decoder receiving layer T0 can begin decoding layer T1 190 at any point. 192 A "Layer Index" is a numeric label for a specific spatial and 193 temporal layer of a scalable stream. It consists of the pair of a 194 "temporal ID" identifying the temporal layer, and a "layer ID" 195 identifying the spatial or quality layer. The details of how layers 196 of a scalable stream are labeled are codec-specific. Details for 197 several codecs are defined in Section 4. 199 3. Layer Refresh Request 201 A layer refresh frame can be requested by sending a Layer Refresh 202 Request (LRR), which is an RTP Control Protocol (RTCP) [RFC3550] 203 payload-specific feedback message [RFC4585] asking the encoder to 204 encode a frame which makes it possible to upgrade to a higher layer. 205 The LRR contains one or two tuples, indicating the temporal and 206 spatial layer the decoder wants to upgrade to, and (optionally) the 207 currently highest temporal and spatial layer the decoder can decode. 209 The specific format of the tuples, and the mechanism by which a 210 receiver recognizes a refresh frame, is codec-dependent. Usage for 211 several codecs is discussed in Section 4. 213 LRR follows the model of the Full Intra Request (FIR) [RFC5104] 214 (Section 3.5.1) for its retransmission, reliability, and use in 215 multipoint conferences. 217 The LRR message is identified by RTCP packet type value PT=PSFB and 218 FMT=TBD. The FCI field MUST contain one or more LRR entries. Each 219 entry applies to a different media sender, identified by its SSRC. 221 [NOTE TO RFC Editor: Please replace "TBD" with the IANA-assigned 222 payload-specific feedback number.] 224 3.1. Message Format 226 The Feedback Control Information (FCI) for the Layer Refresh Request 227 consists of one or more FCI entries, the content of which is depicted 228 in Figure 5. The length of the LRR feedback message MUST be set to 229 2+3*N 32-bit words, where N is the number of FCI entries. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | SSRC | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Seq nr. |C| Payload Type| Reserved | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | RES | TTID| TLID | RES | CTID| CLID | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 5 243 SSRC (32 bits) The SSRC value of the media sender that is requested 244 to send a layer refresh point. 246 Seq nr. (8 bits) Command sequence number. The sequence number space 247 is unique for each pairing of the SSRC of command source and the 248 SSRC of the command target. The sequence number SHALL be 249 increased by 1 for each new command (modulo 256, so the value 250 after 255 is 0). A repetition SHALL NOT increase the sequence 251 number. The initial value is arbitrary. 253 C (1 bit) A flag bit indicating whether the "Current Temporal Layer 254 ID (CTID)" and "Current Layer ID (CLID)" fields are present in the 255 FCI. If this bit is 0, the sender of the LRR message is 256 requesting refresh of all layers up to and including the target 257 layer. 259 Payload Type (7 bits) The RTP payload type for which the LRR is 260 being requested. This gives the context in which the target layer 261 index is to be interpreted. 263 Reserved (RES) (three separate fields, 16 bits / 5 bits / 5 bits) 264 All bits SHALL be set to 0 by the sender and SHALL be ignored on 265 reception. 267 Target Temporal Layer ID (TTID) (3 bits) The temporal ID of the 268 target layer for which the receiver wishes a refresh point. 270 Target Layer ID (TLID) (8 bits) The layer ID of the target spatial 271 or quality layer for which the receiver wishes a refresh point. 272 Its format is dependent on the payload type field. 274 Current Temporal Layer ID (CTID) (3 bits) If C is 1, the ID of the 275 current temporal layer being decoded by the receiver. This 276 message is not requesting refresh of layers at or below this 277 layer. If C is 0, this field SHALL be set to 0 by the sender and 278 SHALL be ignored on reception. 280 Current Layer ID (CLID) (8 bits) If C is 1, the layer ID of the 281 current spatial or quality layer being decoded by the receiver. 282 This message is not requesting refresh of layers at or below this 283 layer. If C is 0, this field SHALL be set to 0 by the sender and 284 SHALL be ignored on reception. 286 When C is 1, TTID MUST NOT be less than CTID, and TLID MUST NOT be 287 less than CLID; at least one of TTID or TLID MUST be greater than 288 CTID or CLID respectively. That is to say, the target layer index 289 MUST be a layer upgrade from the current layer index 290 . A sender MAY request an upgrade in both temporal and 291 spatial/quality layers simultaneously. 293 A receiver receiving an LRR feedback packet which does not satisfy 294 the requirements of the previous paragraph, i.e. one where the C bit 295 is present but TTID is less than CTID or TLID is less than CLID, MUST 296 discard the request. 298 Note: the syntax of the TTID, TLID, CTID, and CLID fields match, by 299 design, the TID and LID fields in [I-D.ietf-avtext-framemarking]. 301 3.2. Semantics 303 Within the common packet header for feedback messages (as defined in 304 section 6.1 of [RFC4585]), the "SSRC of packet sender" field 305 indicates the source of the request, and the "SSRC of media source" 306 is not used and SHALL be set to 0. The SSRCs of the media senders to 307 which the LRR command applies are in the corresponding FCI entries. 308 A LRR message MAY contain requests to multiple media senders, using 309 one FCI entry per target media sender. 311 Upon reception of LRR, the encoder MUST send a decoder refresh point 312 (see Section 2.1) as soon as possible. 314 The sender MUST respect bandwidth limits provided by the application 315 of congestion control, as described in Section 5 of [RFC5104]. As 316 layer refresh points will often be larger than non-refreshing frames, 317 this may restrict a sender's ability to send a layer refresh point 318 quickly. 320 LRR MUST NOT be sent as a reaction to picture losses due to packet 321 loss or corruption -- it is RECOMMENDED to use PLI [RFC4585] instead. 322 LRR SHOULD be used only in situations where there is an explicit 323 change in decoders' behavior, for example when a receiver will start 324 decoding a layer which it previously had been discarding. 326 4. Usage with specific codecs 328 In order for LRR to be used with a scalable codec, the format of the 329 temporal and layer ID fields (for both the target and current layer 330 indices) needs to be specified for that codec's RTP packetization. 331 New RTP packetization specifications for scalable codecs SHOULD 332 define how this is done. (The VP9 payload [I-D.ietf-payload-vp9], 333 for instance, has done so.) If the payload also specifies how it is 334 used with the Frame Marking RTP Header Extension 335 [I-D.ietf-avtext-framemarking], the syntax MUST be defined in the 336 same manner as the TID and LID fields in that header. 338 4.1. H264 SVC 340 H.264 SVC [RFC6190] defines temporal, dependency (spatial), and 341 quality scalability modes. 343 +---------------+---------------+ 344 |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | RES | TID |R| DID | QID | 347 +---------------+---------------+ 349 Figure 6 351 Figure 6 shows the format of the layer index fields for H.264 SVC 352 streams. The "R" and "RES" fields MUST be set to 0 on transmission 353 and ignored on reception. See [RFC6190] Section 1.1.3 for details on 354 the DID, QID, and TID fields. 356 A dependency or quality layer refresh of a given layer in H.264 SVC 357 can be identified by the "I" bit (idr_flag) in the extended NAL unit 358 header, present in NAL unit types 14 (prefix NAL unit) and 20 (coded 359 scalable slice). Layer refresh of the base layer can also be 360 identified by its NAL unit type of its coded slices, which is "5" 361 rather than "1". A dependency or quality layer refresh is complete 362 once this bit has been seen on all the appropriate layers (in 363 decoding order) above the current layer index (if any, or beginning 364 from the base layer if not) through the target layer index. 366 Note that as the "I" bit in a PACSI header is set if the 367 corresponding bit is set in any of the aggregated NAL units it 368 describes; thus, it is not sufficient to identify layer refresh when 369 NAL units of multiple dependency or quality layers are aggregated. 371 In H.264 SVC, temporal layer refresh information can be determined 372 from various Supplemental Encoding Information (SEI) messages in the 373 bitstream. 375 Whether an H.264 SVC stream is scalably nested can be determined from 376 the Scalability Information SEI message's temporal_id_nesting flag. 377 If this flag is set in a stream's currently applicable Scalability 378 Information SEI, receivers SHOULD NOT send temporal LRR messages for 379 that stream, as every frame is implicitly a temporal layer refresh 380 point. (The Scalability Information SEI message may also be 381 available in the signaling negotiation of H.264 SVC, as the sprop- 382 scalability-info parameter.) 384 If a stream's temporal_id_nesting flag is not set, the Temporal Level 385 Switching Point SEI message identifies temporal layer switching 386 points. A temporal layer refresh is satisfied when this SEI message 387 is present in a frame with the target layer index, if the message's 388 delta_frame_num refers to a frame with the requested current layer 389 index. (Alternately, temporal layer refresh can also be satisfied by 390 a complete state refresh, such as an IDR.) Senders which support 391 receiving LRR for non-temporally-nested streams MUST insert Temporal 392 Level Switching Point SEI messages as appropriate. 394 4.2. VP8 396 The VP8 RTP payload format [RFC7741] defines temporal scalability 397 modes. It does not support spatial scalability. 399 +---------------+---------------+ 400 |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | RES | TID | RES | 403 +---------------+---------------+ 405 Figure 7 407 Figure 7 shows the format of the layer index field for VP8 streams. 408 The "RES" fields MUST be set to 0 on transmission and be ignored on 409 reception. See [RFC7741] Section 4.2 for details on the TID field. 411 A VP8 layer refresh point can be identified by the presence of the 412 "Y" bit in the VP8 payload header. When this bit is set, this and 413 all subsequent frames depend only on the current base temporal layer. 415 On receipt of an LRR for a VP8 stream, A sender which supports LRR 416 MUST encode the stream so it can set the Y bit in a packet whose 417 temporal layer is at or below the target layer index. 419 Note that in VP8, not every layer switch point can be identified by 420 the Y bit, since the Y bit implies layer switch of all layers, not 421 just the layer in which it is sent. Thus the use of LRR with VP8 can 422 result in some inefficiency in transmision. However, this is not 423 expected to be a major issue for temporal structures in normal use. 425 4.3. H265 427 The initial version of the H.265 payload format [RFC7798] defines 428 temporal scalability, with protocol elements reserved for spatial or 429 other scalability modes (which are expected to be defined in a future 430 version of the specification). 432 +---------------+---------------+ 433 |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | RES | TID |RES| LayerId | 436 +---------------+---------------+ 438 Figure 8 440 Figure 8 shows the format of the layer index field for H.265 streams. 441 The "RES" fields MUST be set to 0 on transmission and ignored on 442 reception. See [RFC7798] Section 1.1.4 for details on the LayerId 443 and TID fields. 445 H.265 streams signal whether they are temporally nested, using the 446 vps_temporal_id_nesting_flag in the Video Parameter Set (VPS), and 447 the sps_temporal_id_nesting_flag in the Sequence Parameter Set (SPS). 448 If this flag is set in a stream's currently applicable VPS or SPS, 449 receivers SHOULD NOT send temporal LRR messages for that stream, as 450 every frame is implicitly a temporal layer refresh point. 452 If a stream's sps_temporal_id_nesting_flag is not set, the NAL unit 453 types 2 to 5 inclusively identify temporal layer switching points. A 454 layer refresh to any higher target temporal layer is satisfied when a 455 NAL unit type of 4 or 5 with TID equal to 1 more than current TID is 456 seen. Alternatively, layer refresh to a target temporal layer can be 457 incrementally satisfied with NAL unit type of 2 or 3. In this case, 458 given current TID = TO and target TID = TN, layer refresh to TN is 459 satisfied when NAL unit type of 2 or 3 is seen for TID = T1, then TID 460 = T2, all the way up to TID = TN. During this incremental process, 461 layer refresh to TN can be completely satisfied as soon as a NAL unit 462 type of 2 or 3 is seen. 464 Of course, temporal layer refresh can also be satisfied whenever any 465 Intra Random Access Point (IRAP) NAL unit type (with values 16-23, 466 inclusively) is seen. An IRAP picture is similar to an IDR picture 467 in H.264 (NAL unit type of 5 in H.264) where decoding of the picture 468 can start without any older pictures. 470 In the (future) H.265 payloads that support spatial scalability, a 471 spatial layer refresh of a specific layer can be identified by NAL 472 units with the requested layer ID and NAL unit types between 16 and 473 21 inclusive. A dependency or quality layer refresh is complete once 474 NAL units of this type have been seen on all the appropriate layers 475 (in decoding order) above the current layer index (if any, or 476 beginning from the base layer if not) through the target layer index. 478 5. Usage with different scalability transmission mechanisms 480 Several different mechanisms are defined for how scalable streams can 481 be transmitted in RTP. The RTP Taxonomy [RFC7656] Section 3.7 482 defines three mechanisms: Single RTP Stream on a Single Media 483 Transport (SRST), Multiple RTP Streams on a Single Media Transport 484 (MRST), and Multiple RTP Streams on Multiple Media Transports (MRMT). 486 The LRR message is applicable to all these mechanisms. For MRST and 487 MRMT mechanisms, the "media source" field of the LRR FCI is set to 488 the SSRC of the RTP stream containing the layer indicated by the 489 Current Layer Index (if "C" is 1), or the stream containing the base 490 encoded stream (if "C" is 0). For MRMT, it is sent on the RTP 491 session on which this stream is sent. On receipt, the sender MUST 492 refresh all the layers requested in the stream, simultaneously in 493 decode order. 495 6. SDP Definitions 497 Section 7 of [RFC5104] defines SDP procedures for indicating and 498 negotiating support for codec control messages (CCM) in SDP. This 499 document extends this with a new codec control command, "lrr", which 500 indicates support of the Layer Refresh Request (LRR). 502 Figure 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] 503 showing this grammar extension, extending the grammar defined in 504 [RFC5104]. 506 rtcp-fb-ccm-param =/ SP "lrr" ; Layer Refresh Request 508 Figure 9: Syntax of the "lrr" ccm 510 The Offer-Answer considerations defined in [RFC5104] Section 7.2 511 apply. 513 7. Security Considerations 515 All the security considerations of FIR feedback packets [RFC5104] 516 apply to LRR feedback packets as well. Additionally, media senders 517 receiving LRR feedback packets MUST validate that the payload types 518 and layer indices they are receiving are valid for the stream they 519 are currently sending, and discard the requests if not. 521 8. IANA Considerations 523 This document defines a new entry to the "Codec Control Messages" 524 subregistry of the "Session Description Protocol (SDP) Parameters" 525 registry, according to the following data: 527 Value name: lrr 529 Long name: Layer Refresh Request Command 531 Usable with: ccm 533 Mux: IDENTICAL-PER-PT 535 Reference: RFC XXXX 537 This document also defines a new entry to the "FMT Values for PSFB 538 Payload Types" subregistry of the "Real-Time Transport Protocol (RTP) 539 Parameters" registry, according to the following data: 541 Name: LRR 543 Long Name: Layer Refresh Request Command 545 Value: TBD 547 Reference: RFC XXXX 549 9. References 551 9.1. Normative References 553 [I-D.ietf-avtext-framemarking] 554 Berger, E., Nandakumar, S., and M. Zanaty, "Frame Marking 555 RTP Header Extension", draft-ietf-avtext-framemarking-04 556 (work in progress), March 2017. 558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 560 RFC2119, March 1997, 561 . 563 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 564 Jacobson, "RTP: A Transport Protocol for Real-Time 565 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 566 July 2003, . 568 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 569 "Extended RTP Profile for Real-time Transport Control 570 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 571 10.17487/RFC4585, July 2006, 572 . 574 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 575 "Codec Control Messages in the RTP Audio-Visual Profile 576 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 577 February 2008, . 579 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 580 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 581 RFC5234, January 2008, 582 . 584 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 585 "RTP Payload Format for Scalable Video Coding", RFC 6190, 586 DOI 10.17487/RFC6190, May 2011, 587 . 589 [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 590 Galligan, "RTP Payload Format for VP8 Video", RFC 7741, 591 DOI 10.17487/RFC7741, March 2016, 592 . 594 [RFC7798] Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. 595 Hannuksela, "RTP Payload Format for High Efficiency Video 596 Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798, March 597 2016, . 599 9.2. Informative References 601 [I-D.ietf-payload-vp9] 602 Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D. 603 Hong, "RTP Payload Format for VP9 Video", draft-ietf- 604 payload-vp9-03 (work in progress), March 2017. 606 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 607 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 608 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 609 DOI 10.17487/RFC7656, November 2015, 610 . 612 [RFC8082] Wenger, S., Lennox, J., Burman, B., and M. Westerlund, 613 "Using Codec Control Messages in the RTP Audio-Visual 614 Profile with Feedback with Layered Codecs", RFC 8082, DOI 615 10.17487/RFC8082, March 2017, 616 . 618 Authors' Addresses 620 Jonathan Lennox 621 Vidyo, Inc. 622 433 Hackensack Avenue 623 Seventh Floor 624 Hackensack, NJ 07601 625 US 627 Email: jonathan@vidyo.com 629 Danny Hong 630 Vidyo, Inc. 631 433 Hackensack Avenue 632 Seventh Floor 633 Hackensack, NJ 07601 634 US 636 Email: danny@vidyo.com 638 Justin Uberti 639 Google, Inc. 640 747 6th Street South 641 Kirkland, WA 98033 642 USA 644 Email: justin@uberti.name 645 Stefan Holmer 646 Google, Inc. 647 Kungsbron 2 648 Stockholm 111 22 649 Sweden 651 Email: holmer@google.com 653 Magnus Flodman 654 Google, Inc. 655 Kungsbron 2 656 Stockholm 111 22 657 Sweden 659 Email: mflodman@google.com