idnits 2.17.1 draft-ietf-avtext-lrr-06.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 15, 2017) is 2507 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 17, 2017 J. Uberti 6 S. Holmer 7 M. Flodman 8 Google 9 June 15, 2017 11 The Layer Refresh Request (LRR) RTCP Feedback Message 12 draft-ietf-avtext-lrr-06 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 17, 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 . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4. Usage with specific codecs . . . . . . . . . . . . . . . . . 7 62 4.1. H264 SVC . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4.3. H265 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5. Usage with different scalability transmission mechanisms . . 10 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 7. SDP Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 9.2. Informative References . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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, layer refresh typically requires 103 that a spatial layer be encoded in a way that references only lower- 104 layer subpictures of the current picture, not any earlier pictures of 105 that spatial layer. Additionally, the encoder must promise that no 106 earlier pictures of that spatial layer will be used as reference in 107 the future. 109 In a layer refresh, however, other layers than the ones requested for 110 refresh may still maintain dependency on earlier content of the 111 stream. This is the difference between a layer refresh and a Full 112 Intra Request [RFC5104]. This minimizes the coding overhead of 113 refresh to only those parts of the stream that actually need to be 114 refreshed at any given time. 116 An illustration of spatial layer refresh of an enhancement layer is 117 shown below. 119 ... <-- S1 <-- S1 S1 <-- S1 <-- ... 120 | | | | 121 \/ \/ \/ \/ 122 ... <-- S0 <-- S0 <-- S0 <-- S0 <-- ... 124 1 2 3 4 126 Figure 1 128 In Figure 1, frame 3 is a layer refresh point for spatial layer S1; a 129 decoder which had previously only been decoding spatial layer S0 130 would be able to decode layer S1 starting at frame 3. 132 An illustration of spatial layer refresh of a base layer is shown 133 below. 135 ... <-- S1 <-- S1 <-- S1 <-- S1 <-- ... 136 | | | | 137 \/ \/ \/ \/ 138 ... <-- S0 <-- S0 S0 <-- S0 <-- ... 140 1 2 3 4 142 Figure 2 144 In Figure 2, frame 3 is a layer refresh point for spatial layer S0; a 145 decoder which had previously not been decoding the stream at all 146 could decode layer S0 starting at frame 3. 148 For temporal layers, layer refresh requires that the layer be 149 "temporally nested", i.e. use as reference only earlier frames of a 150 lower temporal layer, not any earlier frames of this temporal layer, 151 and also promise that no future frames of this temporal layer will 152 reference frames of this temporal layer before the refresh point. In 153 many cases, the temporal structure of the stream will mean that all 154 frames are temporally nested, in which case decoders will have no 155 need to send LRR messages for the stream. 157 An illustration of temporal layer refresh is shown below. 159 ... <----- T1 <------ T1 T1 <------ ... 160 / / / 161 |_ |_ |_ 162 ... <-- T0 <------ T0 <------ T0 <------ T0 <--- ... 164 1 2 3 4 5 6 7 166 Figure 3 168 In Figure 3, frame 6 is a layer refresh point for temporal layer T1; 169 a decoder which had previously only been decoding temporal layer T0 170 would be able to decode layer T1 starting at frame 6. 172 An illustration of an inherently temporally nested stream is shown 173 below. 175 T1 T1 T1 176 / / / 177 |_ |_ |_ 178 ... <-- T0 <------ T0 <------ T0 <------ T0 <--- ... 180 1 2 3 4 5 6 7 182 Figure 4 184 In Figure 4, the stream is temporally nested in its ordinary 185 structure; a decoder receiving layer T0 can begin decoding layer T1 186 at any point. 188 A "Layer Index" is a numeric label for a specific spatial and 189 temporal layer of a scalable stream. It consists of the pair of a 190 "temporal ID" identifying the temporal layer, and a "layer ID" 191 identifying the spatial or quality layer. The details of how layers 192 of a scalable stream are labeled are codec-specific. Details for 193 several codecs are defined in Section 4. 195 3. Layer Refresh Request 197 A layer refresh frame can be requested by sending a Layer Refresh 198 Request (LRR), which is an RTP Control Protocol (RTCP) [RFC3550] 199 payload-specific feedback message [RFC4585] asking the encoder to 200 encode a frame which makes it possible to upgrade to a higher layer. 201 The LRR contains one or two tuples, indicating the temporal and 202 spatial layer the decoder wants to upgrade to, and (optionally) the 203 currently highest temporal and spatial layer the decoder can decode. 205 The specific format of the tuples, and the mechanism by which a 206 receiver recognizes a refresh frame, is codec-dependent. Usage for 207 several codecs is discussed in Section 4. 209 LRR follows the model of the Full Intra Request (FIR) [RFC5104] 210 (Section 3.5.1) for its retransmission, reliability, and use in 211 multipoint conferences. 213 The LRR message is identified by RTCP packet type value PT=PSFB and 214 FMT=TBD. The FCI field MUST contain one or more LRR entries. Each 215 entry applies to a different media sender, identified by its SSRC. 217 [NOTE TO RFC Editor: Please replace "TBD" with the IANA-assigned 218 payload-specific feedback number.] 220 3.1. Message Format 222 The Feedback Control Information (FCI) for the Layer Refresh Request 223 consists of one or more FCI entries, the content of which is depicted 224 in Figure 5. The length of the LRR feedback message MUST be set to 225 2+3*N, where N is the number of FCI entries. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | SSRC | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Seq nr. |C| Payload Type| Reserved | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | RES | TTID| TLID | RES | CTID| CLID (opt) | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 5 239 SSRC (32 bits) The SSRC value of the media sender that is requested 240 to send a layer refresh point. 242 Seq nr. (8 bits) Command sequence number. The sequence number space 243 is unique for each pairing of the SSRC of command source and the 244 SSRC of the command target. The sequence number SHALL be 245 increased by 1 modulo 256 for each new command. A repetition 246 SHALL NOT increase the sequence number. The initial value is 247 arbitrary. 249 C (1 bit) A flag bit indicating whether the "Current Temporal Layer 250 ID (CTID)" and "Current Layer ID (CLID)" fields are present in the 251 FCI. If this bit is 0, the sender of the LRR message is 252 requesting refresh of all layers up to and including the target 253 layer. 255 Payload Type (7 bits) The RTP payload type for which the LRR is 256 being requested. This gives the context in which the target layer 257 index is to be interpreted. 259 Reserved (RES) (16 bits / 5 bits / 5 bits) All bits SHALL be set to 260 0 by the sender and SHALL be ignored on reception. 262 Target Temporal Layer ID (TTID) (3 bits) The temporal ID of the 263 target layer for which the receiver wishes a refresh point. 265 Target Layer ID (TLID) (8 bits) The layer ID of the target spatial 266 or quality layer for which the receiver wishes a refresh point. 267 Its format is dependent on the payload type field. 269 Current Temporal Layer ID (CTID) (3 bits) If C is 1, the ID of the 270 current temporal layer being decoded by the receiver. This 271 message is not requesting refresh of layers at or below this 272 layer. If C is 0, this field SHALL be set to 0 by the sender and 273 SHALL be ignored on reception. 275 Current Layer ID (CLID) (8 bits) If C is 1, the layer ID of the 276 current spatial or quality layer being decoded by the receiver. 277 This message is not requesting refresh of layers at or below this 278 layer. If C is 0, this field SHALL be set to 0 by the sender and 279 SHALL be ignored on reception. 281 When C is 1, TTID MUST NOT be less than CTID, and TLID MUST NOT be 282 less than CLID; at least one of TTID or TLID MUST be greater than 283 CTID or CLID respectively. That is to say, the target layer index 284 MUST be a layer upgrade from the current layer index 285 . A sender MAY request an upgrade in both temporal and 286 spatial/quality layers simultaneously. 288 Note: the syntax of the TTID, TLID, CTID, and CLID fields match, by 289 design, the TID and LID fields in [I-D.ietf-avtext-framemarking]. 291 3.2. Semantics 293 Within the common packet header for feedback messages (as defined in 294 section 6.1 of [RFC4585]), the "SSRC of packet sender" field 295 indicates the source of the request, and the "SSRC of media source" 296 is not used and SHALL be set to 0. The SSRCs of the media senders to 297 which the LRR command applies are in the corresponding FCI entries. 298 A LRR message MAY contain requests to multiple media senders, using 299 one FCI entry per target media sender. 301 Upon reception of LRR, the encoder MUST send a decoder refresh point 302 (see Section 2.1) as soon as possible. 304 The sender MUST respect bandwidth limits provided by the application 305 of congestion control, as described in Section 5 of [RFC5104]. As 306 layer refresh points will often be larger than non-refreshing frames, 307 this may restrict a sender's ability to send a layer refresh point 308 quickly. 310 LRR MUST NOT be sent as a reaction to picture losses -- it is 311 RECOMMENDED to use PLI [RFC4585] instead. LRR SHOULD be used only in 312 situations where not sending a layer refresh point would render the 313 video unusable for the users. 315 4. Usage with specific codecs 317 In order for LRR to be used with a scalable codec, the format of the 318 temporal and layer ID fields (for both the target and current layer 319 indices) needs to be specified for that codec's RTP packetization. 320 New RTP packetization specifications for scalable codecs SHOULD 321 define how this is done. (The VP9 payload [I-D.ietf-payload-vp9], 322 for instance, has done so.) If the payload also specifies how it is 323 used with the Frame Marking RTP Header Extension 324 [I-D.ietf-avtext-framemarking], the syntax MUST be defined in the 325 same manner as the TID and LID fields in that header. 327 4.1. H264 SVC 329 H.264 SVC [RFC6190] defines temporal, dependency (spatial), and 330 quality scalability modes. 332 +---------------+---------------+ 333 |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | RES | TID |R| DID | QID | 336 +---------------+---------------+ 338 Figure 6 340 Figure 6 shows the format of the layer index fields for H.264 SVC 341 streams. The "R" and "RES" fields MUST be set to 0 on transmission 342 and ignored on reception. See [RFC6190] Section 1.1.3 for details on 343 the DID, QID, and TID fields. 345 A dependency or quality layer refresh of a given layer in H.264 SVC 346 can be identified by the "I" bit (idr_flag) in the extended NAL unit 347 header, present in NAL unit types 14 (prefix NAL unit) and 20 (coded 348 scalable slice). Layer refresh of the base layer can also be 349 identified by its NAL unit type of its coded slices, which is "5" 350 rather than "1". A dependency or quality layer refresh is complete 351 once this bit has been seen on all the appropriate layers (in 352 decoding order) above the current layer index (if any, or beginning 353 from the base layer if not) through the target layer index. 355 Note that as the "I" bit in a PACSI header is set if the 356 corresponding bit is set in any of the aggregated NAL units it 357 describes; thus, it is not sufficient to identify layer refresh when 358 NAL units of multiple dependency or quality layers are aggregated. 360 In H.264 SVC, temporal layer refresh information can be determined 361 from various Supplemental Encoding Information (SEI) messages in the 362 bitstream. 364 Whether an H.264 SVC stream is scalably nested can be determined from 365 the Scalability Information SEI message's temporal_id_nesting flag. 366 If this flag is set in a stream's currently applicable Scalability 367 Information SEI, receivers SHOULD NOT send temporal LRR messages for 368 that stream, as every frame is implicitly a temporal layer refresh 369 point. (The Scalability Information SEI message may also be 370 available in the signaling negotiation of H.264 SVC, as the sprop- 371 scalability-info parameter.) 373 If a stream's temporal_id_nesting flag is not set, the Temporal Level 374 Switching Point SEI message identifies temporal layer switching 375 points. A temporal layer refresh is satisfied when this SEI message 376 is present in a frame with the target layer index, if the message's 377 delta_frame_num refers to a frame with the requested current layer 378 index. (Alternately, temporal layer refresh can also be satisfied by 379 a complete state refresh, such as an IDR.) Senders which support 380 receiving LRR for non-temporally-nested streams MUST insert Temporal 381 Level Switching Point SEI messages as appropriate. 383 4.2. VP8 385 The VP8 RTP payload format [RFC7741] defines temporal scalability 386 modes. It does not support spatial scalability. 388 +---------------+---------------+ 389 |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | RES | TID | RES | 392 +---------------+---------------+ 394 Figure 7 396 Figure 7 shows the format of the layer index field for VP8 streams. 397 The "RES" fields MUST be set to 0 on transmission and be ignored on 398 reception. See [RFC7741] Section 4.2 for details on the TID field. 400 A VP8 layer refresh point can be identified by the presence of the 401 "Y" bit in the VP8 payload header. When this bit is set, this and 402 all subsequent frames depend only on the current base temporal layer. 403 On receipt of an LRR for a VP8 stream, A sender which supports LRR 404 MUST encode the stream so it can set the Y bit in a packet whose 405 temporal layer is at or below the target layer index. 407 Note that in VP8, not every layer switch point can be identified by 408 the Y bit, since the Y bit implies layer switch of all layers, not 409 just the layer in which it is sent. Thus the use of LRR with VP8 can 410 result in some inefficiency in transmision. However, this is not 411 expected to be a major issue for temporal structures in normal use. 413 4.3. H265 415 The initial version of the H.265 payload format [RFC7798] defines 416 temporal scalability, with protocol elements reserved for spatial or 417 other scalability modes (which are expected to be defined in a future 418 version of the specification). 420 +---------------+---------------+ 421 |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | RES | TID |RES| LayerId | 424 +---------------+---------------+ 426 Figure 8 428 Figure 8 shows the format of the layer index field for H.265 streams. 429 The "RES" fields MUST be set to 0 on transmission and ignored on 430 reception. See [RFC7798] Section 1.1.4 for details on the LayerId 431 and TID fields. 433 H.265 streams signal whether they are temporally nested, using the 434 vps_temporal_id_nesting_flag in the Video Parameter Set (VPS), and 435 the sps_temporal_id_nesting_flag in the Sequence Parameter Set (SPS). 436 If this flag is set in a stream's currently applicable VPS or SPS, 437 receivers SHOULD NOT send temporal LRR messages for that stream, as 438 every frame is implicitly a temporal layer refresh point. 440 If a stream's sps_temporal_id_nesting_flag is not set, the NAL unit 441 types 2 to 5 inclusively identify temporal layer switching points. A 442 layer refresh to any higher target temporal layer is satisfied when a 443 NAL unit type of 4 or 5 with TID equal to 1 more than current TID is 444 seen. Alternatively, layer refresh to a target temporal layer can be 445 incrementally satisfied with NAL unit type of 2 or 3. In this case, 446 given current TID = TO and target TID = TN, layer refresh to TN is 447 satisfied when NAL unit type of 2 or 3 is seen for TID = T1, then TID 448 = T2, all the way up to TID = TN. During this incremental process, 449 layer refresh to TN can be completely satisfied as soon as a NAL unit 450 type of 2 or 3 is seen. 452 Of course, temporal layer refresh can also be satisfied whenever any 453 Intra Random Access Point (IRAP) NAL unit type (with values 16-23, 454 inclusively) is seen. An IRAP picture is similar to an IDR picture 455 in H.264 (NAL unit type of 5 in H.264) where decoding of the picture 456 can start without any older pictures. 458 In the (future) H.265 payloads that support spatial scalability, a 459 spatial layer refresh of a specific layer can be identified by NAL 460 units with the requested layer ID and NAL unit types between 16 and 461 21 inclusive. A dependency or quality layer refresh is complete once 462 NAL units of this type have been seen on all the appropriate layers 463 (in decoding order) above the current layer index (if any, or 464 beginning from the base layer if not) through the target layer index. 466 5. Usage with different scalability transmission mechanisms 468 Several different mechanisms are defined for how scalable streams can 469 be transmitted in RTP. The RTP Taxonomy [RFC7656] Section 3.7 470 defines three mechanisms: Single RTP Stream on a Single Media 471 Transport (SRST), Multiple RTP Streams on a Single Media Transport 472 (MRST), and Multiple RTP Streams on Multiple Media Transports (MRMT). 474 The LRR message is applicable to all these mechanisms. For MRST and 475 MRMT mechanisms, the "media source" field of the LRR FCI is set to 476 the SSRC of the RTP stream containing the layer indicated by the 477 Current Layer Index (if "C" is 1), or the stream containing the base 478 encoded stream (if "C" is 0). For MRMT, it is sent on the RTP 479 session on which this stream is sent. On receipt, the sender MUST 480 refresh all the layers requested in the stream, simultaneously in 481 decode order. 483 6. Security Considerations 485 All the security considerations of FIR feedback packets [RFC5104] 486 apply to LRR feedback packets as well. Additionally, media senders 487 receiving LRR feedback packets MUST validate that the payload types 488 and layer indices they are receiving are valid for the stream they 489 are currently sending, and discard the requests if not. 491 7. SDP Definitions 493 Section 7 of [RFC5104] defines SDP procedures for indicating and 494 negotiating support for codec control messages (CCM) in SDP. This 495 document extends this with a new codec control command, "lrr", which 496 indicates support of the Layer Refresh Request (LRR). 498 Figure 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] 499 showing this grammar extension, extending the grammar defined in 500 [RFC5104]. 502 rtcp-fb-ccm-param =/ SP "lrr" ; Layer Refresh Request 504 Figure 9: Syntax of the "lrr" ccm 506 The Offer-Answer considerations defined in [RFC5104] Section 7.2 507 apply. 509 8. IANA Considerations 511 This document defines a new entry to the "Codec Control Messages" 512 subregistry of the "Session Description Protocol (SDP) Parameters" 513 registry, according to the following data: 515 Value name: lrr 517 Long name: Layer Refresh Request Command 519 Usable with: ccm 521 Reference: RFC XXXX 522 This document also defines a new entry to the "FMT Values for PSFB 523 Payload Types" subregistry of the "Real-Time Transport Protocol (RTP) 524 Parameters" registry, according to the following data: 526 Name: LRR 528 Long Name: Layer Refresh Request Command 530 Value: TBD 532 Reference: RFC XXXX 534 9. References 536 9.1. Normative References 538 [I-D.ietf-avtext-framemarking] 539 Berger, E., Nandakumar, S., and M. Zanaty, "Frame Marking 540 RTP Header Extension", draft-ietf-avtext-framemarking-04 541 (work in progress), March 2017. 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 545 RFC2119, March 1997, 546 . 548 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 549 Jacobson, "RTP: A Transport Protocol for Real-Time 550 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 551 July 2003, . 553 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 554 "Extended RTP Profile for Real-time Transport Control 555 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 556 10.17487/RFC4585, July 2006, 557 . 559 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 560 "Codec Control Messages in the RTP Audio-Visual Profile 561 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 562 February 2008, . 564 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 565 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 566 RFC5234, January 2008, 567 . 569 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 570 "RTP Payload Format for Scalable Video Coding", RFC 6190, 571 DOI 10.17487/RFC6190, May 2011, 572 . 574 [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 575 Galligan, "RTP Payload Format for VP8 Video", RFC 7741, 576 DOI 10.17487/RFC7741, March 2016, 577 . 579 [RFC7798] Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. 580 Hannuksela, "RTP Payload Format for High Efficiency Video 581 Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798, March 582 2016, . 584 9.2. Informative References 586 [I-D.ietf-payload-vp9] 587 Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D. 588 Hong, "RTP Payload Format for VP9 Video", draft-ietf- 589 payload-vp9-03 (work in progress), March 2017. 591 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 592 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 593 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 594 DOI 10.17487/RFC7656, November 2015, 595 . 597 [RFC8082] Wenger, S., Lennox, J., Burman, B., and M. Westerlund, 598 "Using Codec Control Messages in the RTP Audio-Visual 599 Profile with Feedback with Layered Codecs", RFC 8082, DOI 600 10.17487/RFC8082, March 2017, 601 . 603 Authors' Addresses 605 Jonathan Lennox 606 Vidyo, Inc. 607 433 Hackensack Avenue 608 Seventh Floor 609 Hackensack, NJ 07601 610 US 612 Email: jonathan@vidyo.com 613 Danny Hong 614 Vidyo, Inc. 615 433 Hackensack Avenue 616 Seventh Floor 617 Hackensack, NJ 07601 618 US 620 Email: danny@vidyo.com 622 Justin Uberti 623 Google, Inc. 624 747 6th Street South 625 Kirkland, WA 98033 626 USA 628 Email: justin@uberti.name 630 Stefan Holmer 631 Google, Inc. 632 Kungsbron 2 633 Stockholm 111 22 634 Sweden 636 Email: holmer@google.com 638 Magnus Flodman 639 Google, Inc. 640 Kungsbron 2 641 Stockholm 111 22 642 Sweden 644 Email: mflodman@google.com