idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-video-lc-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 (March 30, 2016) is 2943 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 March 30, 2016 5 Expires: September 30, 2016 7 RTCP XR Report Block for Loss Concealment Metrics Reporting on 8 Video Applications 9 draft-ietf-xrblock-rtcp-xr-video-lc-06 11 Abstract 13 This document defines a new RTCP XR Report Block that allows the 14 reporting of loss concealment metrics for video applications of RTP. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright and License Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . . 3 56 1.2 Performance Metrics Framework . . . . . . . . . . . . . . . 3 57 1.3 Applicability . . . . . . . . . . . . . . . . . . . . . . . 3 58 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3 Video Loss Concealment Methods . . . . . . . . . . . . . . . . 4 60 4 Video Loss Concealment Report Block . . . . . . . . . . . . . . 5 61 5 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 5.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . . 9 63 5.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . . 9 64 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 65 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 66 7.1 New RTCP XR Block Type Value . . . . . . . . . . . . . . . . 10 67 7.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 10 68 7.3 Contact Information for registrations . . . . . . . . . . . 10 69 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 70 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9.1 Normative References . . . . . . . . . . . . . . . . . . . 10 72 9.2 Informative References . . . . . . . . . . . . . . . . . . 11 73 Appendix A. Metrics Represented Using the Template from RFC 6390 . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 76 1 Introduction 78 Multimedia applications often suffer from packet losses in IP 79 networks. In order to get a reasonable degree of quality in case of 80 packet losses, it is necessary to have loss concealment mechanisms at 81 the decoder. Video loss concealment is a range of techniques to mask 82 the effects of packet loss in video communications. 84 In some applications, reporting the information of receivers applying 85 video loss concealment could give monitors or senders useful 86 information on application QoE. One example is no-reference video 87 quality evaluation. Video probes located upstream from the video 88 endpoint or terminal may not see loss occurring between the probe and 89 the endpoint, and may also not be fully aware of the specific loss 90 concealment methods being dynamically applied by the video endpoint. 91 Evaluating error concealment is important in the circumstance in 92 estimating the subjective impact of impairments. 94 This draft defines one new video loss concealment block type to 95 augment those defined in [RFC3611] and [RFC7294] for use in a range 96 of RTP video applications. The metrics defined in this draft belong 97 to the class of transport-related terminal metrics defined in 98 [RFC6792]. 100 1.1 RTCP and RTCP XR Reports 102 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 103 defines an extensible structure for reporting using an RTCP Extended 104 Report (XR). This draft defines a new Extended Report block that is 105 used as defined in [RFC3550] and [RFC3611]. 107 1.2 Performance Metrics Framework 109 The Performance Metrics Framework [RFC6390] provides guidance on the 110 definition and specification of performance metrics. The RTP 111 Monitoring Architectures [RFC6792] provides guidelines for reporting 112 block format using RTCP XR. The XR block type described in this 113 document are in accordance with the guidelines in [RFC6390] and 114 [RFC6792]. 116 1.3 Applicability 118 These metrics are applicable to video applications the video 119 component of Audio/Video applications using RTP and applying packet 120 loss concealment mechanisms which are incorporated into the receiving 121 endpoint to mitigate the impact of network impairments on QoE. For 122 example, in an IPTV system Set Top Boxes could use this RTCP XR block 123 to report loss and loss concealment metrics to an IPTV management 124 system to enable the service provider to monitor the quality of the 125 IPTV service being delivered to end users. 127 2 Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 3 Video Loss Concealment Methods 135 Video loss concealment mechanisms can be classified into 4 types as 136 follow: 138 a) Frame freeze 140 The impaired video frame is not displayed, instead, the previously 141 displayed frame is frozen for the duration of the loss event. 143 b) Inter-frame extrapolation 145 If an area of the video frame is damaged by loss, the same area from 146 the previous frame(s) can be used to estimate what the missing pixels 147 would have been. This can work well in a scene with no motion but can 148 be very noticeable if there is significant movement from one frame to 149 another. Simple decoders can simply re-use the pixels that were in 150 the missing area while more complex decoders can try to use several 151 frames to do a more complex extrapolation. Another example of a 152 sophisticated form of inter-frame repair is to estimate the motion of 153 the damaged region based on the motion of surrounding regions, and 154 use that to select what part of the previous frame to use for repair. 155 Some important frames, such as IDR frames, may not depend on any 156 other frames and may be involved in a scene change. Using inter-frame 157 extrapolation method to conceal the loss of these frames may not 158 obtain a quite satisfactory result. 160 c) Interpolation 162 A decoder uses the undamaged pixels in the video frame to estimate 163 what the missing block of pixels should have. 165 d) Error Resilient Encoding 167 The sender encodes the message in a redundant way so that receiver 168 can correct errors using the redundant information. There are usually 169 two kinds of Error Resilient Encoding: One is that the redundant data 170 useful for error resiliency performed at the decoder can be embedded 171 into the compressed image/video bitstream. The other is bit-block 172 level encoding, e.g., FEC. 174 Usually, methods b,c,d are deployed together to provide a 175 comprehensive loss concealment in some complex decoders, while method 176 a is relatively independent and may be only applied in some simple 177 decoders. Moreover, frame freeze method repairs video based on frames 178 while the other methods repair video based on fine-grained elements, 179 such as macroblock or bit-block, which will cause the measurement 180 metrics of frame freeze and the other methods slightly different. 181 Thus, In this document, we differentiate between frame freeze and the 182 other 3 concealment mechanisms described. 184 4 Video Loss Concealment Report Block 186 This block reports the video loss concealment metrics to complement 187 the audio metrics defined in [RFC7294]. The report block MUST be sent 188 in conjunction with the information from the Measurement Information 189 Block [RFC6776]. Instances of this metric block refer by SSRC to the 190 separate auxiliary Measurement Information Block [RFC6776]. This 191 metric block relies on the measurement period in the Measurement 192 Information Block indicating the span of the report. If the 193 measurement period is not received in the same compound RTCP packet 194 as this metric block, this metric block MUST be discarded at the 195 receiving side. The metrics in this report block are based on 196 measurements that are typically made at the time that a video frame 197 is decoded and rendered for playout. 199 The video loss concealment report block has the following format: 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | BT=VLC | I | V | RSV | block length | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | SSRC of Source | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Impaired Duration | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Concealed Duration | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Mean Frame Freeze Duration (optional) | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | MIFP | MCFP | FFSC | Reserved | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 1: Format for the Video Loss Concealment Report Block 219 Block Type (BT): 8 bits 220 A Video Loss Concealment Report Block is identified by the 221 constant VLC. 223 [Note to RFC Editor: Please replace VLC with the IANA provided 224 RTCP XR block type for this block.] 226 Interval Metric Flag (I): 2 bits 228 This field indicates whether the reported metrics are interval, 229 cumulative, or sampled metrics [RFC6792]: 231 I=10: Interval Duration - the reported value applies to the 232 most recent measurement interval duration between successive 233 metrics reports. 235 I=11: Cumulative Duration - the reported value applies to the 236 accumulation period characteristic of cumulative measurements. 238 I=01: Sampled Value - this value MUST NOT be used for this 239 block type. 241 I=00: Reserved. 243 Video Loss Concealment Method Type (V): 2 bits 245 This field is used to identify the video loss concealment method 246 type used at the receiver. The value is defined as follow: 248 V=10 - Frame freeze 249 V=11 - Other Loss Concealment Method 250 V=01&00 - Reserved 252 If Frame freeze and other loss concealment method are used 253 together for the media stream, 2 report blocks, one with V=10 for 254 frame freeze and one with V=11 for other loss concealment method 255 SHOULD be compounded together to report the whole concealment 256 information. 258 RSV: 4 bits 260 These bits are reserved for future use. They MUST be set to zero 261 by senders and ignored by receivers (see Section 4.2 of 262 [RFC6709]). 264 block length: 16 bits 266 This field is in accordance with the definition in [RFC3611]. In 267 this report block, it MUST be set to 5 when V=10 and be set to 4 268 when V=11. The block MUST be discarded if the block length is set 269 to a different value. 271 SSRC of source: 32 bits 273 As defined in Section 4.1 of [RFC3611]. 275 Impaired Duration: 32 bits 277 The total time length, expressed in units of RTP timestamp from 278 the sending side of the reporting block, of video impaired by 279 transmission loss before applying any loss concealment methods. 281 Two values are reserved: A value of 0xFFFFFFFE indicates out of 282 range (that is, a measured value exceeding 0xFFFFFFFD) and a value 283 of 0xFFFFFFFF indicates that the measurement is unavailable. 285 Concealed Duration: 32 bits 287 The total time length, expressed in units of RTP timestamp from 288 the sending side of the reporting block, of concealed damaged 289 video pictures on which loss concealment method corresponding to 290 Video Loss Concealment Method Type is applied. 292 Two values are reserved: A value of 0xFFFFFFFE indicates out of 293 range (that is, a measured value exceeding 0xFFFFFFFD) and a value 294 of 0xFFFFFFFF indicates that the measurement is unavailable. 296 Mean Frame Freeze Duration: 32 bits 298 Mean Frame Freeze Duration is the mean duration, expressed in 299 units of RTP timestamp from the sending side of the reporting 300 block, of the frame freeze events. The value of Mean Frame Freeze 301 Duration is calculated by summing the total duration of all frame 302 freeze events and dividing by the number of events. This metric is 303 optional. It only exists when Video Loss Concealment Method 304 Type=10. 306 Mean Impaired Frame Proportion (MIFP): 8 bits 308 Mean Impaired Frame Proportion is the mean proportion of each 309 video frame impaired by loss before applying any loss concealment 310 method during the interval, expressed as a fixed point number with 311 the binary point at the left edge of the field. It is calculated 312 by summing the impaired proportion of each video frame and 313 dividing by the number of frames during this period. The impaired 314 proportion of each video frame is obtained by dividing the number 315 of missing macroblocks from this video frame by the total 316 macroblock number of the video frame, which is equivalent to 317 multiplying the result of the division by 256, limiting the 318 maximum value to 255 (to avoid overflow), and taking the integer 319 part. 321 If a video frame is totally lost, a value of 0xFF SHOULD be used 322 for the frame when calculating the mean value. 324 Mean Concealed Frame Proportion (MCFP): 8 bits 326 Mean Concealed Frame Proportion is the mean proportion of each 327 video frame to which loss concealment (depicted as "V" in the 328 definition of "Video Loss Concealment Method Type") was applied 329 during the interval, expressed as a fixed point number with the 330 binary point at the left edge of the field. It is calculated by 331 summing the concealed proportion of each video frame and dividing 332 by the number of frames during this period. The concealed 333 proportion of each video frame is obtained by dividing the number 334 of concealed macroblocks from this video frame by the total 335 macroblock number of the video frame, which is equivalent to 336 multiplying the result of the division by 256, limiting the 337 maximum value to 255 (to avoid overflow), and taking the integer 338 part. 340 If a lost video frame is totally concealed, a value of 0xFF and if 341 there are no concealed macroblocks, a value of 0, SHOULD be used 342 for the frame when calculating the mean value. For Video Loss 343 Concealment Method Type=10, each frame covered in the period of 344 frame freeze is considered to be totally concealed, which means a 345 value of 0xFF MUST be assigned. 347 Fraction of Frames Subject to Concealment (FFSC): 8 bits 349 Fraction of Frames Subject to Concealment is calculated by 350 dividing the number of frames to which loss concealment (using 351 Video Loss Concealment Method Type) was applied by the total 352 number of frames and expressing this value as a fixed point number 353 with the binary point at the left edge of the field. It is 354 equivalent to multiplying the result of the division by 256, 355 limiting the maximum value to 255 (to avoid overflow), and taking 356 the integer part. 358 A value of 0 indicates that there were no concealed frame and a 359 value of 0xFF indicates that the frames in the entire measurement 360 interval are all concealed. 362 Reserved: 8 bits 364 These bits are reserved for future use. They MUST be set to zero 365 by senders and ignored by receivers (see Section 4.2 of 366 [RFC6709]). 368 5 SDP Signaling 370 [RFC3611] defines the use of SDP (Session Description Protocol) for 371 signaling the use of RTCP XR blocks. 373 5.1 SDP rtcp-xr-attrib Attribute Extension 375 This session augments the SDP attribute "rtcp-xr" defined in Section 376 5.1 of [RFC3611] by providing an additional value of "xr-format" to 377 signal the use of the report block defined in this document. 379 xr-format =/ xr-vlc-block 381 xr-vlc-block = "vlc" 383 5.2 Offer/Answer Usage 385 When SDP is used in offer-answer context, the SDP Offer/Answer usage 386 defined in section 5.2 of [RFC3611] for unilateral "rtcp-xr" 387 attribute parameters applies. For detailed usage of Offer/Answer for 388 unilateral parameter, refer to section 5.2 of [RFC3611]. 390 6 Security Considerations 392 It is believed that this RTCP XR block introduces no new security 393 considerations beyond those described in [RFC3611]. This block does 394 not provide per-packet statistics, so the risk to confidentially 395 documented in Section 7, paragraph 3 of [RFC3611] does not apply. 397 An attacker is likely to put incorrect information in the Video Loss 398 Concealment reports, which will affect the estimation of video loss 399 concealment mechanisms performance and QoE of users. Implementers 400 SHOULD consider the guidance in [RFC7202] for using appropriate 401 security mechanisms, i.e., where security is a concern, the 402 implementation SHOULD apply encryption and authentication to the 403 report block. For example, this can be achieved by using the AVPF 404 profile together with the Secure RTP profile as defined in [RFC3711]; 405 an appropriate combination of the two profiles (an "SAVPF") is 406 specified in [RFC5124]. However, other mechanisms also exist 407 (documented in [RFC7201]) and might be more suitable. 409 7 IANA Considerations 410 New block types for RTCP XR are subject to IANA registration. For 411 general guidelines on IANA considerations for RTCP XR, please refer 412 to [RFC3611]. 414 7.1 New RTCP XR Block Type Value 416 This document assigns the block type value VLC in the IANA "RTP 417 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 418 the "Video Loss Concealment Metric Report Block". 420 [Note to RFC Editor: please replace VLC with the IANA provided RTCP 421 XR block type for this block.] 423 7.2 New RTCP XR SDP Parameter 425 This document also registers a new parameter "video-loss-concealment" 426 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 427 Description Protocol (SDP) Parameters Registry". 429 7.3 Contact Information for registrations 431 The contact information for the registration is: 433 RAI Area Directors 435 rai-ads@tools.ietf.org 437 8 Acknowledgements 439 The author would like to thank Colin Perkins, Roni Even for their 440 valuable comments. 442 9 References 444 9.1 Normative References 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, March 1997. 449 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 451 Jacobson, "RTP: A Transport Protocol for Real-Time 452 Applications", STD 64, RFC 3550, July 2003. 454 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 455 "RTP Control Protocol Extended Reports (RTCP XR)", RFC 456 3611, November 2003. 458 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 459 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 460 RFC 3711, March 2004. 462 [RFC5124] Ott, J., and E. Carrara, "Extended Secure RTP Profile for 463 Real-time Transport Control Protocol (RTCP)-Based Feedback 464 (RTP/SAVPF)", RFC 5124, February 2008. 466 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 467 Reporting Using a Source Description (SDES) Item and an 468 RTCP Extended Report (XR) Block", RFC6776, October 2012. 470 [RFC7294] Clark, A., Zorn, G., Bi, C. and Q., Wu, "RTCP XR Report 471 Block for Concealment Metrics Reporting on Audio 472 Applications", April 2014. 474 9.2 Informative References 476 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 477 Performance Metric Development", BCP 170, RFC 6390, 478 October 2011. 480 [RFC6709] Carpenter, B., and S. Cheshire, "Design Considerations for 481 Protocol Extensions", RFC 6709, September 2012. 483 [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the 484 RTP Monitoring Framework", RFC 6792, November 2012. 486 [RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP 487 Sessions", RFC 7201, April 2014. 489 [RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP 490 Framework: Why RTP Does Not Mandate a Single Media 491 Security Solution", RFC 7202, April 2014. 493 Appendix A. Metrics Represented Using the Template from RFC 6390 495 a. Video Impaired Duration Metric 497 * Metric Name: Video Impaired Duration Metric 499 * Metric Description: The total time length of video impaired by 500 transmission loss before applying any loss concealment methods. 502 * Method of Measurement or Calculation: The metric is based on 503 measurements that are typically made at the time that a video 504 frame is decoded and rendered for playout. 506 * Units of Measurement: This metric is expressed in units of RTP 507 timestamp. 509 * Measurement Point(s) with Potential Measurement Domain: It is 510 measured at the receiving end of the RTP stream. 512 * Measurement Timing: See paragraph 1 of Section 4. 514 * Use and Applications: The metric is applicable to video 515 applications of RTP and the video component of Audio/Video 516 applications in which packet loss concealment mechanisms are 517 applied to the receiving endpoint to mitigate the impact of 518 network impairments on QoE. 520 b. Video Concealed Duration Metric 522 * Metric Name: Video Concealed Duration Metric 524 * Metric Description: The total time length of concealed damaged 525 video pictures on which loss concealment method corresponding to 526 Video Loss Concealment Method Type is applied. 528 * Method of Measurement or Calculation: The metric is based on 529 measurements that are typically made at the time that a video 530 frame is decoded and rendered for playout. 532 * Units of Measurement: This metric is expressed in units of RTP 533 timestamp. 535 * Measurement Point(s) with Potential Measurement Domain: It is 536 measured at the receiving end of the RTP stream. 538 * Measurement Timing: See paragraph 1 of Section 4. 540 * Use and Applications: These metrics are applicable to video 541 applications of RTP and the video component of Audio/Video 542 applications in which packet loss concealment mechanisms are 543 incorporated into the receiving endpoint to mitigate the impact of 544 network impairments on QoE. 546 c. Mean Video Frame Freeze Duration Metric 548 * Metric Name: Mean Video Frame Freeze Duration Metric 550 * Metric Description: The mean duration of the frame freeze 551 events. 553 * Method of Measurement or Calculation: The metric is based on 554 measurements that are typically made at the time that a video 555 frame is decoded and rendered for playout. The metric is 556 calculated by summing the total duration of all frame freeze 557 events and dividing by the number of events. 559 * Units of Measurement: This metric is expressed in units of RTP 560 timestamp. 562 * Measurement Point(s) with Potential Measurement Domain: It is 563 measured at the receiving end of the RTP stream. 565 * Measurement Timing: See paragraph 1 of Section 4. 567 * Use and Applications: These metrics are applicable to video 568 applications of RTP and the video component of Audio/Video 569 applications in which packet loss concealment mechanisms are 570 incorporated into the receiving endpoint to mitigate the impact of 571 network impairments on QoE. 573 d. Mean Impaired Video Frame Proportion Metric 575 * Metric Name: Mean Impaired Video Frame Proportion Metric 577 * Metric Description: Mean proportion of each video frame impaired 578 by loss before applying any loss concealment method during the 579 interval. 581 * Method of Measurement or Calculation: The metric is based on 582 measurements that are typically made at the time that a video 583 frame is decoded and rendered for playout. It is calculated by 584 summing the impaired proportion of each video frame and dividing 585 by the number of frames during this period. The impaired 586 proportion of each video frame is obtained by dividing the number 587 of missing macroblocks from this video frame by the total 588 macroblock number of the video frame, which is equivalent to 589 multiplying the result of the division by 256, limiting the 590 maximum value to 255 (to avoid overflow), and taking the integer 591 part. 593 * Units of Measurement: This metric is expressed as a fixed point 594 number with the binary point at the left edge of the field. 596 * Measurement Point(s) with Potential Measurement Domain: It is 597 measured at the receiving end of the RTP stream. 599 * Measurement Timing: See paragraph 1 of Section 4. 601 * Use and Applications: These metrics are applicable to video 602 applications of RTP and the video component of Audio/Video 603 applications in which packet loss concealment mechanisms are 604 incorporated into the receiving endpoint to mitigate the impact of 605 network impairments on QoE. 607 e. Mean Concealed Video Frame Proportion Metric 609 * Metric Name: Mean Concealed Video Frame Proportion Metric 611 * Metric Description: Mean proportion of each video frame to which 612 loss concealment (using Video Loss Concealment Method Type) was 613 applied during the interval. 615 * Method of Measurement or Calculation: The metric is based on 616 measurements that are typically made at the time that a video 617 frame is decoded and rendered for playout. It is calculated by 618 summing the concealed proportion of each video frame and dividing 619 by the number of frames during this period. The concealed 620 proportion of each video frame is obtained by dividing the number 621 of concealed macroblocks from this video frame by the total 622 macroblock number of the video frame, which is equivalent to 623 multiplying the result of the division by 256, limiting the 624 maximum value to 255 (to avoid overflow), and taking the integer 625 part. 627 * Units of Measurement: This metric is expressed as a fixed point 628 number with the binary point at the left edge of the field. 630 * Measurement Point(s) with Potential Measurement Domain: It is 631 measured at the receiving end of the RTP stream. 633 * Measurement Timing: See paragraph 1 of Section 4. 635 * Use and Applications: These metrics are applicable to video 636 applications of RTP and the video component of Audio/Video 637 applications in which packet loss concealment mechanisms are 638 incorporated into the receiving endpoint to mitigate the impact of 639 network impairments on QoE. 641 f. Fraction of Video Frames Subject to Concealment Metric 643 * Metric Name: Fraction of Video Frames Subject to Concealment 644 Metric 646 * Metric Description: Proportion of concealed video frames to 647 which loss concealment (using Video Loss Concealment Method Type) 648 was applied comparing to the total number of frames during the 649 interval. 651 * Method of Measurement or Calculation: The metric is based on 652 measurements that are typically made at the time that a video 653 frame is decoded and rendered for playout. This metric is 654 calculated by dividing the number of frames to which loss 655 concealment (using Video Loss Concealment Method Type) was applied 656 by the total number of frames. It is equivalent to multiplying the 657 result of the division by 256, limiting the maximum value to 255 658 (to avoid overflow), and taking the integer part. 660 * Units of Measurement: This metric is expressed as a fixed point 661 number with the binary point at the left edge of the field. 663 * Measurement Point(s) with Potential Measurement Domain: It is 664 measured at the receiving end of the RTP stream. 666 * Measurement Timing: See paragraph 1 of Section 4. 668 * Use and Applications: These metrics are applicable to video 669 applications of RTP and the video component of Audio/Video 670 applications in which packet loss concealment mechanisms are 671 incorporated into the receiving endpoint to mitigate the impact of 672 network impairments on QoE. 674 Authors' Addresses 676 Rachel Huang 677 Huawei 678 101 Software Avenue, Yuhua District 679 Nanjing 210012 680 China 682 EMail: rachel.huang@huawei.com