idnits 2.17.1 draft-huang-xrblock-rtcp-xr-video-lc-05.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 ([RFC7294], [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 == Line 252 has weird spacing: '...ired by trans...' -- The document date (January 8, 2015) is 3390 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) == Unused Reference: 'RFC4566' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'RFC5105' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'RFC4588' is defined on line 417, 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: July 12, 2015 Telchemy 6 January 8, 2015 8 RTCP XR Report Block for Loss Concealment Metrics Reporting on 9 Video Applications 10 draft-huang-xrblock-rtcp-xr-video-lc-05 12 Abstract 14 This draft defines a new video loss concealment block type to augment 15 those defined in [RFC3611] and [RFC7294] for use in a range of RTP 16 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) 2015 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 . . . . . . . . . . . . . 5 63 5 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . . 7 65 5.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . 9 70 7.3 Contact Information for registrations . . . . . . . . . . . 9 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 a 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 [RFC7294] for use in a range 98 of RTP video applications. The metrics defined in this draft belong 99 to the class of transport-related terminal metrics defined in 100 [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 Video loss concealment mechanisms can be classified into 4 types as 138 follow: 140 a) Frame freeze 142 The impaired video frame is not displayed, instead, the previously 143 displayed frame is 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 In this document, we differentiate between frame freeze and the other 172 3 concealment mechanisms described. 174 4. Video Loss Concealment Report Block 176 This block reports the video loss concealment metrics to complement 177 the audio metrics defined in [i.d-ietf-xrblock-rtcp-xr-loss- 178 concealment]. This block may be stacked with other RTCP packets to 179 form compound RTCP packets and share the average reporting interval 180 calculated by the RTCP method described in [RFC3550]. It should be 181 noted that the metrics in this report block are based on measurements 182 that are typically made at the time that a video frame is decoded and 183 rendered for playout. The metrics in this block MUST be measured at a 184 consistent point. 186 The video loss concealment report block has the following format: 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | BT=VLC | I | V | RSV | block length=6 | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | SSRC of Source | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Impaired Duration | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Concealed Duration | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | MIFP | MCFP | FFSC | MFFD | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Figure 1: Format for the Video Loss Concealment Report Block 204 Block Type (BT): 8 bits 206 A Video Loss Concealment Report Block is identified by the 207 constant VLC. 209 [Note to RFC Editor: Please replace VLC with the IANA provided 210 RTCP XR block type for this block.] 212 Interval Metric Flag (I): 2 bits 214 This field indicates whether the reported metric is an interval, 215 cumulative, or sampled metric [RFC6792]: 217 I=10: Interval Duration - the reported value applies to the 218 most recent measurement interval duration between successive 219 metrics reports. 221 I=11: Cumulative Duration - the reported value applies to the 222 accumulation period characteristic of cumulative measurements. 224 I=01: Sampled Value - this value MUST NOT be used for this 225 block type. 227 I=00: Reserved. 229 Video Loss Concealment Method Type (V): 2 bits 231 This field is used to identify the video loss concealment method 232 type used at the receiver. Each bit indicates one method type, as 233 follow: 235 V=10 - Frame freeze 236 V=11 - Other Loss Concealment Method 237 V=01&00 - Reserved 239 block length: 16 bits 241 This field is in accordance with the definition in [RFC3611]. In 242 this report block, it MUST be set to 6. The block MUST be 243 discarded if the block length is set to a different value. 245 SSRC of source: 32 bits 247 As defined in Section 4.1 of [RFC3611]. 249 Impaired Duration: 32 bits 251 The total time length, expressed in units of RTP timestamp, of 252 video impaired by transmission loss before applying any loss 253 concealment methods. 255 Two values are reserved: A value of 0xFFFFFFFE indicates out of 256 range (that is, a measured value exceeding 0xFFFFFFFD) and a value 257 of 0xFFFFFFFF indicates that the measurement is unavailable. 259 Concealed Duration: 32 bits 261 The total time length, expressed in units of RTP timestamp, of 262 concealed damaged video pictures on which loss concealment method 263 corresponding to V is applied. 265 Two values are reserved: A value of 0xFFFFFFFE indicates out of 266 range (that is, a measured value exceeding 0xFFFFFFFD) and a value 267 of 0xFFFFFFFF indicates that the measurement is unavailable. 269 Mean Impaired Frame Proportion (MIFP): 8 bits 270 Mean Impaired Frame Proportion is the mean proportion of each 271 video frame impaired by loss before applying any loss concealment 272 method during the interval, expressed as a fixed point number with 273 the binary point at the left edge of the field. It is equivalent 274 to taking the integer part after multiplying the loss fraction by 275 256. If a video frame is totally lost, a value of 0xFF shall be 276 used for the frame when calculating the mean value. 278 Mean Concealed Frame Proportion (MCFP): 8 bits 280 Mean Concealed Frame Proportion is the mean proportion of each 281 video frame to which loss concealment (using V) was applied during 282 the interval, expressed as a fixed point number with the binary 283 point at the left edge of the field. It is equivalent to taking 284 the integer part after multiplying the loss fraction by 256. If a 285 lost video frame is totally concealed, a value of 0xFF and if 286 there are no concealed macroblocks, a value of 0, shall be used 287 for the frame when calculating the mean value. 289 Fraction of Frames Subject to Concealment (FFSC): 8 bits 291 Fraction of Frames Subject to Concealment is calculated by 292 dividing the number of frames to which loss concealment (using V) 293 was applied by the total number of frames and expressing this 294 value as a fixed point number with the binary point at the left 295 edge of the field. It is equivalent to taking the integer part 296 after multiplying the loss fraction by 256. A value of 0 indicates 297 that there were no concealed frame and a value of 0xFF indicates 298 that the frames in the entire measurement interval are all 299 concealed. 301 Mean Frame Freeze Duration (MFFD): 8 bits 303 Mean Frame Freeze Duration is the mean duration of the frame 304 freeze events. The value of MFFD shall be calculated by summing 305 the total duration of all frame freeze events and dividing by the 306 number of events. A value of 0xFF shall be used to indicate a 307 value in excess of 12700 milliseconds. A value of 0 MUST be set 308 when V=11. 310 5 SDP Signaling 312 [RFC3611] defines the use of SDP (Session Description Protocol) for 313 signaling the use of RTCP XR blocks. However XR blocks MAY be used 314 without prior signaling (see section 5 of [RFC3611]). 316 5.1 SDP rtcp-xr-attrib Attribute Extension 317 This session augments the SDP attribute "rtcp-xr" defined in Section 318 5.1 of [RFC3611] by providing an additional value of "xr-format" to 319 signal the use of the report block defined in this document. 321 xr-format =/ xr-vlc-block 323 xr-vlc-block = "video-loss-concealment" 325 5.2 Offer/Answer Usage 327 When SDP is used in offer-answer context, the SDP Offer/Answer usage 328 defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters 329 applies. For detailed usage of Offer/Answer for unilateral 330 parameter, refer to section 5.2 of [RFC3611]. 332 6 Security Considerations 334 It is believed that this RTCP XR block introduces no new security 335 considerations beyond those described in [RFC3611]. This block does 336 not provide per-packet statistics, so the risk to confidentially 337 documented in Section 7, paragraph 3 of [RFC3611] does not apply. 339 An attacker may put incorrect information in the Video Loss 340 Concealment reports, which will be affect the estimation of video 341 loss concealment mechanisms performance and QoE of users. 342 Implementers should consider the guidance in [RFC7202] for using 343 appropriate security mechanisms, i.e., where security is a concern, 344 the implementation should apply encryption and authentication to the 345 report block. For example, this can be achieved by using the AVPF 346 profile together with the Secure RTP profile as defined in [RFC3711]; 347 an appropriate combination of the two profiles (an "SAVPF") is 348 specified in [RFC5124]. However, other mechanisms also exist 349 (documented in [RFC7201]) and might be more suitable. 351 7 IANA Considerations 353 New block types for RTCP XR are subject to IANA registration. For 354 general guidelines on IANA considerations for RTCP XR, refer to 355 [RFC3611]. 357 7.1 New RTCP XR Block Type Value 359 This document assigns the block type value VLC in the IANA "RTP 360 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 361 the "Video Loss Concealment Metrics Report Block". 363 [Note to RFC Editor: please replace VLC with the IANA provided RTCP 364 XR block type for this block.] 366 7.2 New RTCP XR SDP Parameter 368 This document also registers a new parameter "video-loss-concealment" 369 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 370 Description Protocol (SDP) Parameters Registry". 372 7.3 Contact Information for registrations 374 The following contact information is provided for all registrations 375 in this document: 377 Rachel Huang (rachel.huang@huawei.com) 379 101 Software Avenue, Yuhua District 380 Nanjing, Jiangsu 210012 381 China 383 8 Acknowledgements 385 The author would like to thank Colin Perkins, Roni Even for their 386 valuable comments. 388 9 References 390 9.1 Normative References 392 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 396 Jacobson, "RTP: A Transport Protocol for Real-Time 397 Applications", STD 64, RFC 3550, July 2003. 399 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 400 "RTP Control Protocol Extended Reports (RTCP XR)", 401 RFC 3611, November 2003. 403 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 404 Description Protocol", RFC 4566, July 2006. 406 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 407 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 408 RFC 3711, March 2004. 410 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 411 Real-time Transport Control Protocol (RTCP)-Based Feedback 412 (RTP/SAVPF)", RFC 5124, February 2008. 414 [RFC5105] Lendl, O., "ENUM Validation Token Format Definition", 415 RFC 5105, December 2007. 417 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 418 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 419 July 2006. 421 [RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP 422 Sessions", RFC 7201, April 2014. 424 [RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP 425 Framework: Why RTP Does Not Mandate a Single Media 426 Security Solution", RFC 7202, April 2014. 428 [RFC7294] Clark, A., Zorn, G., Bi, C. and Q., Wu, "RTCP XR Report 429 Block for Concealment Metrics Reporting on Audio 430 Applications", April 2014. 432 9.2 Informative References 434 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 435 Performance Metric Development", BCP 170, RFC 6390, 436 October 2011. 438 [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the 439 RTP Monitoring Framework", RFC 6792, November 2012. 441 Appendix A. Metrics Represented Using the Template from RFC 6390 443 TBD. 445 Authors' Addresses 447 Rachel Huang 448 Huawei 449 101 Software Avenue, Yuhua District 450 Nanjing 210012 451 China 453 EMail: rachel.huang@huawei.com 455 Alan Clark 456 Telchemy Incorporated 457 2905 Premiere Parkway, Suite 280 458 Duluth, GA 30097 459 USA 461 Email: alan.d.clark@telchemy.com