idnits 2.17.1 draft-huang-xrblock-rtcp-xr-video-lc-03.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3611]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3467 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) == Missing Reference: 'RFC6709' is mentioned on line 298, but not defined == Unused Reference: 'RFC4566' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'RFC5105' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'RFC4588' is defined on line 407, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Downref: Normative reference to an Informational RFC: RFC 7201 ** Downref: Normative reference to an Informational RFC: RFC 7202 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XRBLOCK R. Huang 3 INTERNET-DRAFT Huawei 4 Intended Status: Standards Track A. Clark 5 Expires: April 30, 2015 Telchemy 6 October 27, 2014 8 RTCP XR Report Block for Loss Concealment Metrics Reporting on 9 Video Applications 10 draft-huang-xrblock-rtcp-xr-video-lc-03 12 Abstract 14 This draft defines a new video loss concealment block type to augment 15 those defined in [RFC3611] and [i.d-ietf-xrblock-rtcp-xr-loss- 16 concealment] for use in a range of RTP video applications. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1 RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . . 3 58 1.2 Performance Metrics Framework . . . . . . . . . . . . . . . 3 59 1.3 Applicability . . . . . . . . . . . . . . . . . . . . . . . 3 60 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3 Video Loss Concealment Methods . . . . . . . . . . . . . . . . 4 62 4. Video Loss Concealment Report Block . . . . . . . . . . . . . 4 63 5 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . . 7 65 5.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . . 7 66 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 67 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1 New RTCP XR Block Type Value . . . . . . . . . . . . . . . . 8 69 7.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 8 70 7.3 Contact Information for registrations . . . . . . . . . . . 8 71 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 72 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9.1 Normative References . . . . . . . . . . . . . . . . . . . 9 74 9.2 Informative References . . . . . . . . . . . . . . . . . . 10 75 Appendix A. Metrics Represented Using the Template from RFC 6390 . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1 Introduction 80 Multimedia applications often suffer from packet losses in IP 81 networks. In order to get reasonable degree of quality in case of 82 packet losses, it is necessary to have loss concealment mechanisms at 83 the decoder. Video loss concealment is a range of techniques to mask 84 the effects of packet loss in video communications. 86 In some applications, reporting the information of receivers applying 87 video loss concealment could give monitors or senders useful 88 information on application QoE. One example is no-reference video 89 quality evaluation. Video probes located upstream from the video 90 endpoint or terminal may not see loss occurring between the probe and 91 the endpoint, and may also not be fully aware of the specific loss 92 concealment methods being dynamically applied by the video endpoint. 93 Evaluating error concealment is important in the circumstance in 94 estimating the subjective impact of impairments. 96 This draft defines one new video loss concealment block type to 97 augment those defined in [RFC3611] and [i.d-ietf-xrblock-rtcp-xr- 98 loss-concealment] for use in a range of RTP video applications. The 99 metrics defined in this draft belong to the class of transport- 100 related terminal metrics defined in [RFC6792]. 102 1.1 RTCP and RTCP XR Reports 104 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 105 defines an extensible structure for reporting using an RTCP Extended 106 Report (XR). This draft defines a new Extended Report block that MUST 107 be used as defined in [RFC3550] and [RFC3611]. 109 1.2 Performance Metrics Framework 111 The Performance Metrics Framework [RFC6390] provides guidance on the 112 definition and specification of performance metrics. The RTP 113 Monitoring Architectures [RFC6792] provides guidelines for reporting 114 block format using RTCP XR. The XR block type described in this 115 document are in accordance with the guidelines in [RFC6390] and 116 [RFC6792]. 118 1.3 Applicability 120 These metrics are applicable to video applications of RTP and the 121 video component of Audio/Video applications in which packet loss 122 concealment mechanisms are incorporated into the receiving endpoint 123 to mitigate the impact of network impairments on QoE. For example, in 124 an IPTV system Set Top Boxes could use this RTCP XR block to report 125 loss and loss concealment metrics to an IPTV management system to 126 enable the service provider to monitor the quality of the IPTV 127 service being delivered to end users. 129 2 Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [KEYWORDS]. 135 3 Video Loss Concealment Methods 137 In this draft, video loss concealment mechanisms are classified into 138 4 types as follow: 140 a) Frame freeze 142 The impaired video frame is not displayed, instead, the previously 143 displayed frame is hence frozen for the duration of the loss event. 145 b) Inter-frame extrapolation 147 If an area of the video frame is damaged by loss, the same area from 148 the previous frame(s) can be used to estimate what the missing pixels 149 would have been. This can work well in a scene with no motion but can 150 be very noticeable if there is significant movement from one frame to 151 another. Simple decoders may simply re-use the pixels that were in 152 the missing area while more complex decoders may try to use several 153 frames to do a more complex extrapolation. 155 c) Interpolation 157 A decoder may user the undamaged pixels in the video frame to 158 estimate what the missing block of pixels should have. 160 d) Error Resilient Encoding 162 The sender may encode the message in a redundant way so that receiver 163 can correct errors using the redundant information. The redundant 164 data useful for error resiliency performed at the decoder can be 165 embedded into the compressed image/video bitstream. For example, the 166 encoder may select an important area of an original video frame, 167 extract some important characteristics of this area, e.g., motion 168 vector of each macroblock, and imperceptibly embed them into other 169 parts of the video frame. FEC is also another error resilient method. 171 4. Video Loss Concealment Report Block 173 This block reports the video loss concealment metrics to complement 174 the audio metrics defined in [i.d-ietf-xrblock-rtcp-xr-loss- 175 concealment]. This block may be stacked with other RTCP packets to 176 form compound RTCP packets and share the average reporting interval 177 calculated by the RTCP method described in [RFC3550]. It should be 178 noted that the metrics in this report block are based on measurements 179 that are typically made at the time that a video frame is decoded and 180 rendered for playout. The metrics in this block MUST be measured at a 181 consistent point. 183 The video loss concealment report block has the following format: 185 0 1 2 3 186 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | BT=VLC | I | VLCM | block length=6 | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | SSRC of Source | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Loss Free Video Image Duration | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Loss Impaired Video Image Duration | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | MIFP | MCFP | Reserved | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 1: Format for the Video Loss Concealment Report Block 201 Block Type (BT): 8 bits 203 A Video Loss Concealment Report Block is identified by the 204 constant VLC. 206 [Note to RFC Editor: Please replace VLC with the IANA provided 207 RTCP XR block type for this block.] 209 Interval Metric Flag (I): 2 bits 211 This field indicates whether the reported metric is an interval, 212 cumulative, or sampled metric [RFC6792]: 214 I=10: Interval Duration - the reported value applies to the 215 most recent measurement interval duration between successive 216 metrics reports. 218 I=11: Cumulative Duration - the reported value applies to the 219 accumulation period characteristic of cumulative measurements. 221 I=01: Sampled Value - this value MUST NOT be used for this 222 block type. 224 I=00: Reserved. 226 Video Loss Concealment Method Type (VLCM): 6 bits 228 This field is used to identify the video loss concealment method 229 type used at the receiver. Each bit indicates one method type, as 230 follow: 232 bit 014 - Frame freeze 233 bit 015 - Inter-frame extrapolation 234 bit 016 - Interpolation 235 bit 017 - Error Resilient 236 bit 018 - Other Loss Concealment Method 237 bit 019 - Reserved 239 Setting the bit means corresponding type of mechanisms are used. 240 Multiple types of method are allowed to use together. For example, 241 Applications could use RTP retransmission to recovery some lost 242 packets and use noise insertion to conceal some losses that could 243 not be fixed. 245 block length: 16 bits 247 This field is in accordance with the definition in [RFC3611]. In 248 this report block, it MUST be set to 6. The block MUST be 249 discarded if the block length is set to a different value. 251 SSRC of source: 32 bits 253 As defined in Section 4.1 of [RFC3611]. 255 Loss Free Video Image Duration: 32 bits 257 The total time length, expressed in units of millisecond, of 258 received video with no transmission loss. 260 Two values are reserved: A value of 0xFFFFFFFE indicates out of 261 range (that is, a measured value exceeding 0xFFFFFFFD) and a value 262 of 0xFFFFFFFF indicates that the measurement is unavailable. 264 Loss Impaired Video Image Duration: 32 bits 266 The total time length, expressed in units of millisecond, of still 267 impaired video pictures, which have transmission loss and to which 268 loss concealment may have been applied. 270 Two values are reserved: A value of 0xFFFFFFFE indicates out of 271 range (that is, a measured value exceeding 0xFFFFFFFD) and a value 272 of 0xFFFFFFFF indicates that the measurement is unavailable. 274 Mean Impaired Frame Proportion(MIFP): 8 bits 276 Mean Impaired Frame Proportion is the mean proportion of each 277 video frame impaired by loss during the Loss Impaired Video Image 278 Duration period, expressed as a fixed point number with the binary 279 point at the left edge of the field. It is equivalent to taking 280 the integer part after multiplying the loss fraction by 256. If a 281 video frame is totally lost, the MIFP of this frame is set to 282 0xFF. 284 Mean Concealed Frame Proportion(MCFP): 8 bits 286 Mean Concealed Frame Proportion is the mean proportion of each 287 video frame with concealed loss impairments during the Loss 288 Impaired Video Image Duration period, expressed as a fixed point 289 number with the binary point at the left edge of the field. It is 290 equivalent to taking the integer part after multiplying the loss 291 fraction by 256. If a lost video frame is totally concealed, the 292 MCFP is set to 0xFF; If there are no concealed macroblocks in a 293 lost or partial lost video frame, the MCFP of this frame is set 0. 295 Reserved: 16 bits 297 These bits are reserved. They MUST be set to zero by senders and 298 ignored by receivers (See [RFC6709] section 4.2). 300 5 SDP Signaling 302 [RFC3611] defines the use of SDP (Session Description Protocol) for 303 signaling the use of RTCP XR blocks. However XR blocks MAY be used 304 without prior signaling (see section 5 of [RFC3611]). 306 5.1 SDP rtcp-xr-attrib Attribute Extension 308 This session augments the SDP attribute "rtcp-xr" defined in Section 309 5.1 of [RFC3611] by providing an additional value of "xr-format" to 310 signal the use of the report block defined in this document. 312 xr-format =/ xr-vlc-block 314 xr-vlc-block = "video-loss-concealment" 316 5.2 Offer/Answer Usage 317 When SDP is used in offer-answer context, the SDP Offer/Answer usage 318 defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters 319 applies. For detailed usage of Offer/Answer for unilateral 320 parameter, refer to section 5.2 of [RFC3611]. 322 6 Security Considerations 324 It is believed that this RTCP XR block introduces no new security 325 considerations beyond those described in [RFC3611]. This block does 326 not provide per-packet statistics, so the risk to confidentially 327 documented in Section 7, paragraph 3 of [RFC3611] does not apply. 329 An attacker may put incorrect information in the Video Loss 330 Concealment reports, which will be affect the estimation of video 331 loss concealment mechanisms performance and QoE of users. 332 Implementers should consider the guidance in [RFC7202] for using 333 appropriate security mechanisms, i.e., where security is a concern, 334 the implementation should apply encryption and authentication to the 335 report block. For example, this can be achieved by using the AVPF 336 profile together with the Secure RTP profile as defined in [RFC3711]; 337 an appropriate combination of the two profiles (an "SAVPF") is 338 specified in [RFC5124]. However, other mechanisms also exist 339 (documented in [RFC7201]) and might be more suitable. 341 7 IANA Considerations 343 New block types for RTCP XR are subject to IANA registration. For 344 general guidelines on IANA considerations for RTCP XR, refer to 345 [RFC3611]. 347 7.1 New RTCP XR Block Type Value 349 This document assigns the block type value VLC in the IANA "RTP 350 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 351 the "Video Loss Concealment Metrics Report Block". 353 [Note to RFC Editor: please replace VLC with the IANA provided RTCP 354 XR block type for this block.] 356 7.2 New RTCP XR SDP Parameter 358 This document also registers a new parameter "video-loss-concealment" 359 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 360 Description Protocol (SDP) Parameters Registry". 362 7.3 Contact Information for registrations 364 The following contact information is provided for all registrations 365 in this document: 367 Rachel Huang (rachel.huang@huawei.com) 369 101 Software Avenue, Yuhua District 370 Nanjing, Jiangsu 210012 371 China 373 8 Acknowledgements 375 The author would like to thank Colin Perkins, Roni Even, Jonathan 376 Lennox to provide valuable comments. 378 9 References 380 9.1 Normative References 382 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 385 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 386 Jacobson, "RTP: A Transport Protocol for Real-Time 387 Applications", STD 64, RFC 3550, July 2003. 389 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 390 "RTP Control Protocol Extended Reports (RTCP XR)", 391 RFC 3611, November 2003. 393 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 394 Description Protocol", RFC 4566, July 2006. 396 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 397 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 398 RFC 3711, March 2004. 400 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 401 Real-time Transport Control Protocol (RTCP)-Based Feedback 402 (RTP/SAVPF)", RFC 5124, February 2008. 404 [RFC5105] Lendl, O., "ENUM Validation Token Format Definition", 405 RFC 5105, December 2007. 407 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 408 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 409 July 2006. 411 [RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP 412 Sessions", RFC 7201, April 2014. 414 [RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP 415 Framework: Why RTP Does Not Mandate a Single Media 416 Security Solution", RFC 7202, April 2014. 418 [i.d-ietf-xrblock-rtcp-xr-loss-concealment] Clark, A., Zorn, G., Bi, 419 C. and Q., Wu, "RTCP XR Report Block for Concealment 420 Metrics Reporting on Audio Applications", April 2014. 422 9.2 Informative References 424 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 425 Performance Metric Development", BCP 170, RFC 6390, 426 October 2011. 428 [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the 429 RTP Monitoring Framework", RFC 6792, November 2012. 431 Appendix A. Metrics Represented Using the Template from RFC 6390 433 TBD. 435 Authors' Addresses 437 Rachel Huang 438 Huawei 439 101 Software Avenue, Yuhua District 440 Nanjing 210012 441 China 443 EMail: rachel.huang@huawei.com 445 Alan Clark 446 Telchemy Incorporated 447 2905 Premiere Parkway, Suite 280 448 Duluth, GA 30097 449 USA 451 Email: alan.d.clark@telchemy.com