idnits 2.17.1 draft-ietf-avtext-lrr-02.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 (March 21, 2016) is 2948 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-payload-vp9-01 Summary: 0 errors (**), 0 flaws (~~), 2 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: September 22, 2016 J. Uberti 6 S. Holmer 7 M. Flodman 8 Google 9 March 21, 2016 11 The Layer Refresh Request (LRR) RTCP Feedback Message 12 draft-ietf-avtext-lrr-02 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 September 22, 2016. 38 Copyright Notice 40 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Usage with specific codecs . . . . . . . . . . . . . . . . . 7 62 4.1. H264 SVC . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.3. H265 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5. Usage with different scalability transmission mechanisms . . 10 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 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 [I-D.wenger-avtext-avpf-ccm-layered]). 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 In this illustration, frame 3 is a layer refresh point for spatial 127 layer S1; a decoder which had previously only been decoding spatial 128 layer S0 would be able to decode layer S1 starting at frame 3. 130 Figure 1 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 In this illustration, frame 3 is a layer refresh point for spatial 143 layer S0; a decoder which had previously not been decoding the stream 144 at all could decode layer S0 starting at frame 3. 146 Figure 2 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 In this illustration, frame 6 is a layer refresh point for temporal 167 layer T1; a decoder which had previously only been decoding temporal 168 layer T0 would be able to decode layer T1 starting at frame 6. 170 Figure 3 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 In this illustration, the stream is temporally nested in its ordinary 183 structure; a decoder receiving layer T0 can begin decoding layer T1 184 at any point. 186 Figure 4 188 3. Layer Refresh Request 190 A layer refresh frame can be requested by sending a Layer Refresh 191 Request (LRR), which is an RTCP payload-specific feedback message 192 [RFC4585] asking the encoder to encode a frame which makes it 193 possible to upgrade to a higher layer. The LRR contains one or two 194 tuples, indicating the layer the decoder wants to upgrade to, and 195 (optionally) the currently highest layer the decoder can decode. 197 The specific format of the tuples, and the mechanism by which a 198 receiver recognizes a refresh frame, is codec-dependent. Usage for 199 several codecs is discussed in Section 4. 201 LRR follows the model of the Full Intra Request (FIR) 202 [RFC5104](Section 3.5.1) for its retransmission, reliability, and use 203 in multipoint conferences. 205 The LRR message is identified by RTCP packet type value PT=PSFB and 206 FMT=TBD. The FCI field MUST contain one or more LRR entries. Each 207 entry applies to a different media sender, identified by its SSRC. 209 3.1. Message Format 211 The Feedback Control Information (FCI) for the Layer Refresh Request 212 consists of one or more FCI entries, the content of which is depicted 213 in Figure 5. The length of the LRR feedback message MUST be set to 214 2+3*N, where N is the number of FCI entries. 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | SSRC | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Seq nr. |C| Payload Type| Reserved | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Target Layer Index | Current Layer Index (opt) | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 5 228 SSRC (32 bits) The SSRC value of the media sender that is requested 229 to send a layer refresh point. 231 Seq nr. (8 bits) Command sequence number. The sequence number space 232 is unique for each pairing of the SSRC of command source and the 233 SSRC of the command target. The sequence number SHALL be 234 increased by 1 modulo 256 for each new command. A repetition 235 SHALL NOT increase the sequence number. The initial value is 236 arbitrary. 238 C (1 bit) A flag bit indicating whether the "Current Layer Index" 239 field is present in the FCI. If this bit is false, the sender of 240 the LRR message is requesting refresh of all layers up to and 241 including the target layer. 243 Payload Type (7 bits) The RTP payload type for which the LRR is 244 being requested. This gives the context in which the target layer 245 index is to be interpreted. 247 Reserved (16 bits) All bits SHALL be set to 0 by the sender and 248 SHALL be ignored on reception. 250 Target Layer Index (16 bits) The target layer for which the receiver 251 wishes a refresh point. Its format is dependent on the payload 252 type field. 254 Current Layer Index (16 bits) If C is 1, the current layer being 255 decoded by the receiver. This message is not requesting refresh 256 of layers at or below this layer. If C is 0, this field SHALL be 257 set to 0 by the sender and SHALL be ignored on reception. 259 3.2. Semantics 261 Within the common packet header for feedback messages (as defined in 262 section 6.1 of [RFC4585]), the "SSRC of packet sender" field 263 indicates the source of the request, and the "SSRC of media source" 264 is not used and SHALL be set to 0. The SSRCs of the media senders to 265 which the LRR command applies are in the corresponding FCI entries. 266 A LRR message MAY contain requests to multiple media senders, using 267 one FCI entry per target media sender. 269 Upon reception of LRR, the encoder MUST send a decoder refresh point 270 (see section Section 2.1) as soon as possible. 272 The sender MUST consider congestion control as outlined in section 5 273 of [RFC5104], which MAY restrict its ability to send a layer refresh 274 point quickly. 276 4. Usage with specific codecs 278 In order for LRR to be used with a scalable codec, the format of the 279 target layer and current target layer fields needs to be specified 280 for that codec's RTP packetization. New RTP packetization 281 specifications for scalable codecs SHOULD define how this is done. 282 (The VP9 payload [I-D.ietf-payload-vp9], for instance, has done so.) 283 This section defines the layer index fields for use with several 284 existing scalable codecs. 286 4.1. H264 SVC 288 H.264 SVC [RFC6190] defines temporal, dependency (spatial), and 289 quality scalability modes. 291 +---------------+---------------+ 292 |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 |R| DID | QID | TID |RES | 295 +---------------+---------------+ 297 Figure 6 299 Figure 6 shows the format of the layer index field for H.264 SVC 300 streams. This is designed to follow the same layout as the third and 301 fourth bytes of the H.264 SVC NAL unit extension, which carry the 302 stream's layer information. The "R" and "RES" fields MUST be set to 303 0 on transmission and ignored on reception. See [RFC6190] 304 Section 1.1.3 for details on the DID, QID, and TID fields. 306 A dependency or quality layer refresh of a given layer in H.264 SVC 307 can be identified by the "I" bit (idr_flag) in the extended NAL unit 308 header, present in NAL unit types 14 (prefix NAL unit) and 20 (coded 309 scalable slice). Layer refresh of the base layer can also be 310 identified by its NAL unit type of its coded slices, which is "5" 311 rather than "1". A dependency or quality layer refresh is complete 312 once this bit has been seen on all the appropriate layers (in 313 decoding order) above the current layer index (if any, or beginning 314 from the base layer if not) through the target layer index. 316 Note that as the "I" bit in a PACSI header is set if the 317 corresponding bit is set in any of the aggregated NAL units it 318 describes; thus, it is not sufficient to identify layer refresh when 319 NAL units of multiple dependency or quality layers are aggregated. 321 In H.264 SVC, temporal layer refresh information can be determined 322 from various Supplemental Encoding Information (SEI) messages in the 323 bitstream. 325 Whether an H.264 SVC stream is scalably nested can be determined from 326 the Scalability Information SEI message's temporal_id_nesting flag. 327 If this flag is set in a stream's currently applicable Scalability 328 Information SEI, receivers SHOULD NOT send temporal LRR messages for 329 that stream, as every frame is implicitly a temporal layer refresh 330 point. (The Scalability Information SEI message may also be 331 available in the signaling negotiation of H.264 SVC, as the sprop- 332 scalability-info parameter.) 334 If a stream's temporal_id_nesting flag is not set, the Temporal Level 335 Switching Point SEI message identifies temporal layer switching 336 points. A temporal layer refresh is satisfied when this SEI message 337 is present in a frame with the target layer index, if the message's 338 delta_frame_num refers to a frame with the requested current layer 339 index. (Alternately, temporal layer refresh can also be satisfied by 340 a complete state refresh, such as an IDR.) Senders which support 341 receiving LRR for non-temporally-nested streams MUST insert Temporal 342 Level Switching Point SEI messages as appropriate. 344 4.2. VP8 346 The VP8 RTP payload format [I-D.ietf-payload-vp8] defines temporal 347 scalability modes. It does not support spatial scalability. 349 +---------------+---------------+ 350 |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 |TID| RES | 353 +---------------+---------------+ 355 Figure 7 357 Figure 7 shows the format of the layer index field for VP8 streams. 358 The "RES" fields MUST be set to 0 on transmission and be ignored on 359 reception. See [I-D.ietf-payload-vp8] Section 4.2 for details on the 360 TID field. 362 A VP8 layer refresh point can be identified by the presence of the 363 "Y" bit in the VP8 payload header. When this bit is set, this and 364 all subsequent frames depend only on the current base temporal layer. 365 On receipt of an LRR for a VP8 stream, A sender which supports LRR 366 MUST encode the stream so it can set the Y bit in a packet whose 367 temporal layer is at or below the target layer index. 369 Note that in VP8, not every layer switch point can be identified by 370 the Y bit, since the Y bit implies layer switch of all layers, not 371 just the layer in which it is sent. Thus the use of LRR with VP8 can 372 result in some inefficiency in transmision. However, this is not 373 expected to be a major issue for temporal structures in normal use. 375 4.3. H265 377 The initial version of the H.265 payload format 378 [I-D.ietf-payload-rtp-h265] defines temporal scalability, with 379 protocol elements reserved for spatial or other scalability modes 380 (which are expected to be defined in a future version of the 381 specification). 383 +---------------+---------------+ 384 |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | RES | LayerId | TID | 387 +-------------+-----------------+ 389 Figure 8 391 Figure 8 shows the format of the layer index field for H.265 streams. 392 This is designed to follow the same layout as the first and second 393 bytes of the H.265 NAL unit header, which carry the stream's layer 394 information. The "RES" field MUST be set to 0 on transmission and 395 ignored on reception. See [I-D.ietf-payload-rtp-h265] Section 1.1.4 396 for details on the LayerId and TID fields. 398 H.265 streams signal whether they are temporally nested, using the 399 vps_temporal_id_nesting_flag in the Video Parameter Set (VPS), and 400 the sps_temporal_id_nesting_flag in the Sequence Parameter Set (SPS). 401 If this flag is set in a stream's currently applicable VPS or SPS, 402 receivers SHOULD NOT send temporal LRR messages for that stream, as 403 every frame is implicitly a temporal layer refresh point. 405 If a stream's sps_temporal_id_nesting_flag is not set, the NAL unit 406 types 2 to 5 inclusively identify temporal layer switching points. A 407 layer refresh to any higher target temporal layer is satisfied when a 408 NAL unit type of 4 or 5 with TID equal to 1 more than current TID is 409 seen. Alternatively, layer refresh to a target temporal layer can be 410 incrementally satisfied with NAL unit type of 2 or 3. In this case, 411 given current TID = TO and target TID = TN, layer refresh to TN is 412 satisfied when NAL unit type of 2 or 3 is seen for TID = T1, then TID 413 = T2, all the way up to TID = TN. During this incremental process, 414 layer refresh to TN can be completely satisfied as soon as a NAL unit 415 type of 2 or 3 is seen. 417 Of course, temporal layer refresh can also be satisfied whenever any 418 Intra Random Access Point (IRAP) NAL unit type (with values 16-23, 419 inclusively) is seen. An IRAP picture is similar to an IDR picture 420 in H.264 (NAL unit type of 5 in H.264) where decoding of the picture 421 can start without any older pictures. 423 In the (future) H.265 payloads that support spatial scalability, a 424 spatial layer refresh of a specific layer can be identified by NAL 425 units with the requested layer ID and NAL unit types between 16 and 426 21 inclusive. A dependency or quality layer refresh is complete once 427 NAL units of this type have been seen on all the appropriate layers 428 (in decoding order) above the current layer index (if any, or 429 beginning from the base layer if not) through the target layer index. 431 5. Usage with different scalability transmission mechanisms 433 Several different mechanisms are defined for how scalable streams can 434 be transmitted in RTP. The RTP Taxonomy [RFC7656] Section 3.7 435 defines three mechanisms: Single RTP Stream on a Single Media 436 Transport (SRST), Multiple RTP Streams on a Single Media Transport 437 (MRST), and Multiple RTP Streams on Multiple Media Transports (MRMT). 439 The LRR message is applicable to all these mechanisms. For MRST and 440 MRMT mechanisms, the "media source" field of the LRR FCI is set to 441 the SSRC of the RTP stream containing the layer indicated by the 442 Current Layer Index (if "C" is 1), or the stream containing the base 443 encoded stream (if "C" is 0). For MRMT, it is sent on the RTP 444 session on which this stream is sent. On receipt, the sender MUST 445 refresh all the layers requested in the stream, simultaneously in 446 decode order. 448 6. Security Considerations 450 All the security considerations of FIR feedback packets [RFC5104] 451 apply to LRR feedback packets as well. Additionally, media senders 452 receiving LRR feedback packets MUST validate that the payload types 453 and layer indices they are receiving are valid for the stream they 454 are currently sending, and discard the requests if not. 456 7. SDP Definitions 458 Section 7 of [RFC5104] defines SDP procedures for indicating and 459 negotiating support for codec control messages (CCM) in SDP. This 460 document extends this with a new codec control command, "lrr", which 461 indicates support of the Layer Refresh Request (LRR). 463 Figure 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] 464 showing this grammar extension, extending the grammar defined in 465 [RFC5104]. 467 rtcp-fb-ccm-param =/ SP "lrr" ; Layer Refresh Request 469 Figure 9: Syntax of the "lrr" ccm 471 The Offer-Answer considerations defined in [RFC5104] Section 7.2 472 apply. 474 8. IANA Considerations 476 This document defines a new entry to the "Codec Control Messages" 477 subregistry of the "Session Description Protocol (SDP) Parameters" 478 registry, according to the following data: 480 Value name: lrr 482 Long name: Layer Refresh Request Command 484 Usable with: ccm 486 Reference: RFC XXXX 488 This document also defines a new entry to the "FMT Values for PSFB 489 Payload Types" subregistry of the "Real-Time Transport Protocol (RTP) 490 Parameters" registry, according to the following data: 492 Name: LRR 494 Long Name: Layer Refresh Request Command 496 Value: TBD 498 Reference: RFC XXXX 500 9. References 502 9.1. Normative References 504 [I-D.ietf-payload-rtp-h265] 505 Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. 506 Hannuksela, "RTP Payload Format for H.265/HEVC Video", 507 draft-ietf-payload-rtp-h265-15 (work in progress), 508 November 2015. 510 [I-D.ietf-payload-vp8] 511 Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 512 Galligan, "RTP Payload Format for VP8 Video", draft-ietf- 513 payload-vp8-17 (work in progress), September 2015. 515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 516 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 517 RFC2119, March 1997, 518 . 520 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 521 Jacobson, "RTP: A Transport Protocol for Real-Time 522 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 523 July 2003, . 525 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 526 "Extended RTP Profile for Real-time Transport Control 527 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 528 10.17487/RFC4585, July 2006, 529 . 531 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 532 "Codec Control Messages in the RTP Audio-Visual Profile 533 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 534 February 2008, . 536 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 537 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 538 RFC5234, January 2008, 539 . 541 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 542 "RTP Payload Format for Scalable Video Coding", RFC 6190, 543 DOI 10.17487/RFC6190, May 2011, 544 . 546 9.2. Informative References 548 [I-D.ietf-payload-vp9] 549 Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D. 550 Hong, "RTP Payload Format for VP9 Video", draft-ietf- 551 payload-vp9-01 (work in progress), October 2015. 553 [I-D.wenger-avtext-avpf-ccm-layered] 554 Wenger, S., Lennox, J., Burman, B., and M. Westerlund, 555 "Using Codec Control Messages in the RTP Audio-Visual 556 Profile with Feedback with Layered Codecs", draft-wenger- 557 avtext-avpf-ccm-layered-00 (work in progress), December 558 2015. 560 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 561 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 562 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 563 DOI 10.17487/RFC7656, November 2015, 564 . 566 Authors' Addresses 568 Jonathan Lennox 569 Vidyo, Inc. 570 433 Hackensack Avenue 571 Seventh Floor 572 Hackensack, NJ 07601 573 US 575 Email: jonathan@vidyo.com 577 Danny Hong 578 Vidyo, Inc. 579 433 Hackensack Avenue 580 Seventh Floor 581 Hackensack, NJ 07601 582 US 584 Email: danny@vidyo.com 585 Justin Uberti 586 Google, Inc. 587 747 6th Street South 588 Kirkland, WA 98033 589 USA 591 Email: justin@uberti.name 593 Stefan Holmer 594 Google, Inc. 595 Kungsbron 2 596 Stockholm 111 22 597 Sweden 599 Email: holmer@google.com 601 Magnus Flodman 602 Google, Inc. 603 Kungsbron 2 604 Stockholm 111 22 605 Sweden 607 Email: mflodman@google.com