idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- 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 (November 2, 2015) is 3097 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) ** Downref: Normative reference to an Informational RFC: RFC 6709 Summary: 1 error (**), 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 A. Clark 5 Expires: May 5, 2016 Telchemy 6 November 2, 2015 8 RTCP XR Report Block for Loss Concealment Metrics Reporting on 9 Video Applications 10 draft-ietf-xrblock-rtcp-xr-video-lc-03 12 Abstract 14 This document defines a new RTCP XR Report Block that allows the 15 reporting of loss concealment metrics for video applications of RTP. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright and License Notice 40 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . . 3 57 1.2 Performance Metrics Framework . . . . . . . . . . . . . . . 3 58 1.3 Applicability . . . . . . . . . . . . . . . . . . . . . . . 3 59 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3 Video Loss Concealment Methods . . . . . . . . . . . . . . . . 4 61 4 Video Loss Concealment Report Block . . . . . . . . . . . . . . 5 62 5 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . . 9 64 5.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . . 9 65 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 66 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 67 7.1 New RTCP XR Block Type Value . . . . . . . . . . . . . . . . 10 68 7.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 10 69 7.3 Contact Information for registrations . . . . . . . . . . . 10 70 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 9.1 Normative References . . . . . . . . . . . . . . . . . . . 10 73 9.2 Informative References . . . . . . . . . . . . . . . . . . 11 74 Appendix A. Metrics Represented Using the Template from RFC 6390 . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 77 1 Introduction 79 Multimedia applications often suffer from packet losses in IP 80 networks. In order to get a reasonable degree of quality in case of 81 packet losses, it is necessary to have loss concealment mechanisms at 82 the decoder. Video loss concealment is a range of techniques to mask 83 the effects of packet loss in video communications. 85 In some applications, reporting the information of receivers applying 86 video loss concealment could give monitors or senders useful 87 information on application QoE. One example is no-reference video 88 quality evaluation. Video probes located upstream from the video 89 endpoint or terminal may not see loss occurring between the probe and 90 the endpoint, and may also not be fully aware of the specific loss 91 concealment methods being dynamically applied by the video endpoint. 92 Evaluating error concealment is important in the circumstance in 93 estimating the subjective impact of impairments. 95 This draft defines one new video loss concealment block type to 96 augment those defined in [RFC3611] and [RFC7294] for use in a range 97 of RTP video applications. The metrics defined in this draft belong 98 to the class of transport-related terminal metrics defined in 99 [RFC6792]. 101 1.1 RTCP and RTCP XR Reports 103 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 104 defines an extensible structure for reporting using an RTCP Extended 105 Report (XR). This draft defines a new Extended Report block that is 106 used as defined in [RFC3550] and [RFC3611]. 108 1.2 Performance Metrics Framework 110 The Performance Metrics Framework [RFC6390] provides guidance on the 111 definition and specification of performance metrics. The RTP 112 Monitoring Architectures [RFC6792] provides guidelines for reporting 113 block format using RTCP XR. The XR block type described in this 114 document are in accordance with the guidelines in [RFC6390] and 115 [RFC6792]. 117 1.3 Applicability 119 These metrics are applicable to video applications the video 120 component of Audio/Video applications using RTP and applying packet 121 loss concealment mechanisms which are incorporated into the receiving 122 endpoint to mitigate the impact of network impairments on QoE. For 123 example, in an IPTV system Set Top Boxes could use this RTCP XR block 124 to report loss and loss concealment metrics to an IPTV management 125 system to enable the service provider to monitor the quality of the 126 IPTV service being delivered to end users. 128 2 Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 3 Video Loss Concealment Methods 136 Video loss concealment mechanisms can be classified into 4 types as 137 follow: 139 a) Frame freeze 141 The impaired video frame is not displayed, instead, the previously 142 displayed frame is frozen for the duration of the loss event. 144 b) Inter-frame extrapolation 146 If an area of the video frame is damaged by loss, the same area from 147 the previous frame(s) can be used to estimate what the missing pixels 148 would have been. This can work well in a scene with no motion but can 149 be very noticeable if there is significant movement from one frame to 150 another. Simple decoders can simply re-use the pixels that were in 151 the missing area while more complex decoders can try to use several 152 frames to do a more complex extrapolation. Another example of a 153 sophisticated form of inter-frame repair is to estimate the motion of 154 the damaged region based on the motion of surrounding regions, and 155 use that to select what part of the previous frame to use for repair. 156 Some important frames, such as IDR frames, may not depend on any 157 other frames and may be involved in a scene change. Using inter-frame 158 extrapolation method to conceal the loss of these frames may not 159 obtain a quite satisfactory result. 161 c) Interpolation 163 A decoder uses the undamaged pixels in the video frame to estimate 164 what the missing block of pixels should have. 166 d) Error Resilient Encoding 168 The sender encodes the message in a redundant way so that receiver 169 can correct errors using the redundant information.There are usually 170 two kinds of Error Resilient Encoding: One is that the redundant data 171 useful for error resiliency performed at the decoder can be embedded 172 into the compressed image/video bitstream. For example, the encoder 173 can select a crucial area of an original video frame, extract some 174 important characteristics of this area as the redundant information, 175 e.g., redundant motion vector of the first macroblock in a slice of 176 this area and redundant motion vector difference of other macroblocks 177 in this slice of this area, and imperceptibly embed them into other 178 parts of the video frame sent in a different RTP packet or in the 179 next frame, e.g., other slices of this area. The other is bit-block 180 level encoding, e.g., FEC. 182 Usually, methods b,c,d are deployed together to provide a 183 comprehensive loss concealment in some complex decoders, while method 184 a is relatively independent and may be only applied in some simple 185 decoders. Moreover, frame freeze method repairs video based on frames 186 while the other methods repair video based on fine-grained elements, 187 such as macroblock or bit-block, which will cause the measurement 188 metrics of frame freeze and the other methods slightly different. 189 Thus, In this document, we differentiate between frame freeze and the 190 other 3 concealment mechanisms described. 192 4 Video Loss Concealment Report Block 194 This block reports the video loss concealment metrics to complement 195 the audio metrics defined in [RFC7294]. The report block MUST be sent 196 in conjunction with the information from the Measurement Information 197 Block [RFC6776]. Instances of this metric block refer by SSRC to the 198 separate auxiliary Measurement Information Block [RFC6776]. This 199 metric block relies on the measurement period in the Measurement 200 Information Block indicating the span of the report. If the 201 measurement period is not received in the same compound RTCP packet 202 as this metric block, this metric block MUST be discarded at the 203 receiving side. The metrics in this report block are based on 204 measurements that are typically made at the time that a video frame 205 is decoded and rendered for playout. 207 The video loss concealment report block has the following format: 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | BT=VLC | I | V | RSV | block length | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | SSRC of Source | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Impaired Duration | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Concealed Duration | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Mean Frame Freeze Duration (optional) | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | MIFP | MCFP | FFSC | Reserved | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 1: Format for the Video Loss Concealment Report Block 227 Block Type (BT): 8 bits 229 A Video Loss Concealment Report Block is identified by the 230 constant VLC. 232 [Note to RFC Editor: Please replace VLC with the IANA provided 233 RTCP XR block type for this block.] 235 Interval Metric Flag (I): 2 bits 237 This field indicates whether the reported metrics are interval, 238 cumulative, or sampled metrics [RFC6792]: 240 I=10: Interval Duration - the reported value applies to the 241 most recent measurement interval duration between successive 242 metrics reports. 244 I=11: Cumulative Duration - the reported value applies to the 245 accumulation period characteristic of cumulative measurements. 247 I=01: Sampled Value - this value MUST NOT be used for this 248 block type. 250 I=00: Reserved. 252 Video Loss Concealment Method Type (V): 2 bits 254 This field is used to identify the video loss concealment method 255 type used at the receiver. The value is defined as follow: 257 V=10 - Frame freeze 258 V=11 - Other Loss Concealment Method 259 V=01&00 - Reserved 261 If Frame freeze and other loss concealment method are used 262 together for the media stream, 2 report blocks, one with V=10 for 263 frame freeze and one with V=11 for other loss concealment method 264 SHOULD be compounded together to report the whole concealment 265 information. 267 RSV: 4 bits 268 These bits are reserved for future use. They MUST be set to zero 269 by senders and ignored by receivers (see Section 4.2 of 270 [RFC6709]). 272 block length: 16 bits 274 This field is in accordance with the definition in [RFC3611]. In 275 this report block, it MUST be set to 6 when V=10 and be set to 5 276 when V=11. The block MUST be discarded if the block length is set 277 to a different value. 279 SSRC of source: 32 bits 281 As defined in Section 4.1 of [RFC3611]. 283 Impaired Duration: 32 bits 285 The total time length, expressed in units of RTP timestamp from 286 the sending side of the reporting block, of video impaired by 287 transmission loss before applying any loss concealment methods. 289 Two values are reserved: A value of 0xFFFFFFFE indicates out of 290 range (that is, a measured value exceeding 0xFFFFFFFD) and a value 291 of 0xFFFFFFFF indicates that the measurement is unavailable. 293 Concealed Duration: 32 bits 295 The total time length, expressed in units of RTP timestamp from 296 the sending side of the reporting block, of concealed damaged 297 video pictures on which loss concealment method corresponding to 298 Video Loss Concealment Method Type is applied. 300 Two values are reserved: A value of 0xFFFFFFFE indicates out of 301 range (that is, a measured value exceeding 0xFFFFFFFD) and a value 302 of 0xFFFFFFFF indicates that the measurement is unavailable. 304 Mean Frame Freeze Duration: 32 bits 306 Mean Frame Freeze Duration is the mean duration, expressed in 307 units of RTP timestamp from the sending side of the reporting 308 block, of the frame freeze events. The value of Mean Frame Freeze 309 Duration is calculated by summing the total duration of all frame 310 freeze events and dividing by the number of events. This metric is 311 optional. It only exists when Video Loss Concealment Method 312 Type=10. 314 Mean Impaired Frame Proportion (MIFP): 8 bits 315 Mean Impaired Frame Proportion is the mean proportion of each 316 video frame impaired by loss before applying any loss concealment 317 method during the interval, expressed as a fixed point number with 318 the binary point at the left edge of the field. It is calculated 319 by summing the impaired proportion of each video frame and 320 dividing by the number of frames during this period. The impaired 321 proportion of each video frame is obtained by dividing the number 322 of missing macroblocks from this video frame by the total 323 macroblock number of the video frame, which is equivalent to 324 multiplying the result of the division by 256, limiting the 325 maximum value to 255 (to avoid overflow), and taking the integer 326 part. 328 If a video frame is totally lost, a value of 0xFF SHOULD be used 329 for the frame when calculating the mean value. 331 Mean Concealed Frame Proportion (MCFP): 8 bits 333 Mean Concealed Frame Proportion is the mean proportion of each 334 video frame to which loss concealment (depicted as "V" in the 335 definition of "Video Loss Concealment Method Type") was applied 336 during the interval, expressed as a fixed point number with the 337 binary point at the left edge of the field. It is calculated by 338 summing the concealed proportion of each video frame and dividing 339 by the number of frames during this period. The concealed 340 proportion of each video frame is obtained by dividing the number 341 of concealed macroblocks from this video frame by the total 342 macroblock number of the video frame, which is equivalent to 343 multiplying the result of the division by 256, limiting the 344 maximum value to 255 (to avoid overflow), and taking the integer 345 part. 347 If a lost video frame is totally concealed, a value of 0xFF and if 348 there are no concealed macroblocks, a value of 0, SHOULD be used 349 for the frame when calculating the mean value. For Video Loss 350 Concealment Method Type=10, each frame covered in the period of 351 frame freeze is considered to be totally concealed, which means a 352 value of 0xFF MUST be assigned. 354 Fraction of Frames Subject to Concealment (FFSC): 8 bits 356 Fraction of Frames Subject to Concealment is calculated by 357 dividing the number of frames to which loss concealment (using 358 Video Loss Concealment Method Type) was applied by the total 359 number of frames and expressing this value as a fixed point number 360 with the binary point at the left edge of the field. It is 361 equivalent to multiplying the result of the division by 256, 362 limiting the maximum value to 255 (to avoid overflow), and taking 363 the integer part. 365 A value of 0 indicates that there were no concealed frame and a 366 value of 0xFF indicates that the frames in the entire measurement 367 interval are all concealed. 369 Reserved: 8 bits 371 These bits are reserved for future use. They MUST be set to zero 372 by senders and ignored by receivers (see Section 4.2 of 373 [RFC6709]). 375 5 SDP Signaling 377 [RFC3611] defines the use of SDP (Session Description Protocol) for 378 signaling the use of RTCP XR blocks. 380 5.1 SDP rtcp-xr-attrib Attribute Extension 382 This session augments the SDP attribute "rtcp-xr" defined in Section 383 5.1 of [RFC3611] by providing an additional value of "xr-format" to 384 signal the use of the report block defined in this document. 386 xr-format =/ xr-vlc-block 388 xr-vlc-block = "vlc" 390 5.2 Offer/Answer Usage 392 When SDP is used in offer-answer context, the SDP Offer/Answer usage 393 defined in section 5.2 of [RFC3611] for unilateral "rtcp-xr" 394 attribute parameters applies. For detailed usage of Offer/Answer for 395 unilateral parameter, refer to section 5.2 of [RFC3611]. 397 6 Security Considerations 399 It is believed that this RTCP XR block introduces no new security 400 considerations beyond those described in [RFC3611]. This block does 401 not provide per-packet statistics, so the risk to confidentially 402 documented in Section 7, paragraph 3 of [RFC3611] does not apply. 404 An attacker is likely to put incorrect information in the Video Loss 405 Concealment reports, which will affect the estimation of video loss 406 concealment mechanisms performance and QoE of users. Implementers 407 SHOULD consider the guidance in [RFC7202] for using appropriate 408 security mechanisms, i.e., where security is a concern, the 409 implementation SHOULD apply encryption and authentication to the 410 report block. For example, this can be achieved by using the AVPF 411 profile together with the Secure RTP profile as defined in [RFC3711]; 412 an appropriate combination of the two profiles (an "SAVPF") is 413 specified in [RFC5124]. However, other mechanisms also exist 414 (documented in [RFC7201]) and might be more suitable. 416 7 IANA Considerations 418 New block types for RTCP XR are subject to IANA registration. For 419 general guidelines on IANA considerations for RTCP XR, please refer 420 to [RFC3611]. 422 7.1 New RTCP XR Block Type Value 424 This document assigns the block type value VLC in the IANA "RTP 425 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 426 the "Video Loss Concealment Metric Report Block". 428 [Note to RFC Editor: please replace VLC with the IANA provided RTCP 429 XR block type for this block.] 431 7.2 New RTCP XR SDP Parameter 433 This document also registers a new parameter "video-loss-concealment" 434 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 435 Description Protocol (SDP) Parameters Registry". 437 7.3 Contact Information for registrations 439 The contact information for the registration is: 441 RAI Area Directors 443 rai-ads@tools.ietf.org 445 8 Acknowledgements 447 The author would like to thank Colin Perkins, Roni Even for their 448 valuable comments. 450 9 References 452 9.1 Normative References 454 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 455 Requirement Levels", BCP 14, RFC 2119, March 1997. 457 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 459 Jacobson, "RTP: A Transport Protocol for Real-Time 460 Applications", STD 64, RFC 3550, July 2003. 462 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 463 "RTP Control Protocol Extended Reports (RTCP XR)", RFC 464 3611, November 2003. 466 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 467 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 468 RFC 3711, March 2004. 470 [RFC5124] Ott, J., and E. Carrara, "Extended Secure RTP Profile for 471 Real-time Transport Control Protocol (RTCP)-Based Feedback 472 (RTP/SAVPF)", RFC 5124, February 2008. 474 [RFC6709] Carpenter, B., and S. Cheshire, "Design Considerations for 475 Protocol Extensions", RFC 6709, September 2012. 477 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 478 Reporting Using a Source Description (SDES) Item and an 479 RTCP Extended Report (XR) Block", RFC6776, October 2012. 481 [RFC7294] Clark, A., Zorn, G., Bi, C. and Q., Wu, "RTCP XR Report 482 Block for Concealment Metrics Reporting on Audio 483 Applications", April 2014. 485 9.2 Informative References 487 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 488 Performance Metric Development", BCP 170, RFC 6390, 489 October 2011. 491 [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the 492 RTP Monitoring Framework", RFC 6792, November 2012. 494 [RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP 495 Sessions", RFC 7201, April 2014. 497 [RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP 498 Framework: Why RTP Does Not Mandate a Single Media 499 Security Solution", RFC 7202, April 2014. 501 Appendix A. Metrics Represented Using the Template from RFC 6390 503 a. Video Impaired Duration Metric 505 * Metric Name: Video Impaired Duration Metric 506 * Metric Description: The total time length of video impaired by 507 transmission loss before applying any loss concealment methods. 509 * Method of Measurement or Calculation: The metric is based on 510 measurements that are typically made at the time that a video 511 frame is decoded and rendered for playout. 513 * Units of Measurement: This metric is expressed in units of RTP 514 timestamp. 516 * Measurement Point(s) with Potential Measurement Domain: It is 517 measured at the receiving end of the RTP stream. 519 * Measurement Timing: See paragraph 1 of Section 4. 521 * Use and Applications: The metric is applicable to video 522 applications of RTP and the video component of Audio/Video 523 applications in which packet loss concealment mechanisms are 524 applied to the receiving endpoint to mitigate the impact of 525 network impairments on QoE. 527 b. Video Concealed Duration Metric 529 * Metric Name: Video Concealed Duration Metric 531 * Metric Description: The total time length of concealed damaged 532 video pictures on which loss concealment method corresponding to 533 Video Loss Concealment Method Type is applied. 535 * Method of Measurement or Calculation: The metric is based on 536 measurements that are typically made at the time that a video 537 frame is decoded and rendered for playout. 539 * Units of Measurement: This metric is expressed in units of RTP 540 timestamp. 542 * Measurement Point(s) with Potential Measurement Domain: It is 543 measured at the receiving end of the RTP stream. 545 * Measurement Timing: See paragraph 1 of Section 4. 547 * Use and Applications: These metrics are applicable to video 548 applications of RTP and the video component of Audio/Video 549 applications in which packet loss concealment mechanisms are 550 incorporated into the receiving endpoint to mitigate the impact of 551 network impairments on QoE. 553 c. Mean Video Frame Freeze Duration Metric 554 * Metric Name: Mean Video Frame Freeze Duration Metric 556 * Metric Description: The mean duration of the frame freeze 557 events. 559 * Method of Measurement or Calculation: The metric is based on 560 measurements that are typically made at the time that a video 561 frame is decoded and rendered for playout. The metric is 562 calculated by summing the total duration of all frame freeze 563 events and dividing by the number of events. 565 * Units of Measurement: This metric is expressed in units of RTP 566 timestamp. 568 * Measurement Point(s) with Potential Measurement Domain: It is 569 measured at the receiving end of the RTP stream. 571 * Measurement Timing: See paragraph 1 of Section 4. 573 * Use and Applications: These metrics are applicable to video 574 applications of RTP and the video component of Audio/Video 575 applications in which packet loss concealment mechanisms are 576 incorporated into the receiving endpoint to mitigate the impact of 577 network impairments on QoE. 579 d. Mean Impaired Video Frame Proportion Metric 581 * Metric Name: Mean Impaired Video Frame Proportion Metric 583 * Metric Description: Mean proportion of each video frame impaired 584 by loss before applying any loss concealment method during the 585 interval. 587 * Method of Measurement or Calculation: The metric is based on 588 measurements that are typically made at the time that a video 589 frame is decoded and rendered for playout. It is calculated by 590 summing the impaired proportion of each video frame and dividing 591 by the number of frames during this period. The impaired 592 proportion of each video frame is obtained by dividing the number 593 of missing macroblocks from this video frame by the total 594 macroblock number of the video frame, which is equivalent to 595 multiplying the result of the division by 256, limiting the 596 maximum value to 255 (to avoid overflow), and taking the integer 597 part. 599 * Units of Measurement: This metric is expressed as a fixed point 600 number with the binary point at the left edge of the field. 602 * Measurement Point(s) with Potential Measurement Domain: It is 603 measured at the receiving end of the RTP stream. 605 * Measurement Timing: See paragraph 1 of Section 4. 607 * Use and Applications: These metrics are applicable to video 608 applications of RTP and the video component of Audio/Video 609 applications in which packet loss concealment mechanisms are 610 incorporated into the receiving endpoint to mitigate the impact of 611 network impairments on QoE. 613 e. Mean Concealed Video Frame Proportion Metric 615 * Metric Name: Mean Concealed Video Frame Proportion Metric 617 * Metric Description: Mean proportion of each video frame to which 618 loss concealment (using Video Loss Concealment Method Type) was 619 applied during the interval. 621 * Method of Measurement or Calculation: The metric is based on 622 measurements that are typically made at the time that a video 623 frame is decoded and rendered for playout. It is calculated by 624 summing the concealed proportion of each video frame and dividing 625 by the number of frames during this period. The concealed 626 proportion of each video frame is obtained by dividing the number 627 of concealed macroblocks from this video frame by the total 628 macroblock number of the video frame, which is equivalent to 629 multiplying the result of the division by 256, limiting the 630 maximum value to 255 (to avoid overflow), and taking the integer 631 part. 633 * Units of Measurement: This metric is expressed as a fixed point 634 number with the binary point at the left edge of the field. 636 * Measurement Point(s) with Potential Measurement Domain: It is 637 measured at the receiving end of the RTP stream. 639 * Measurement Timing: See paragraph 1 of Section 4. 641 * Use and Applications: These metrics are applicable to video 642 applications of RTP and the video component of Audio/Video 643 applications in which packet loss concealment mechanisms are 644 incorporated into the receiving endpoint to mitigate the impact of 645 network impairments on QoE. 647 f. Fraction of Video Frames Subject to Concealment Metric 649 * Metric Name: Fraction of Video Frames Subject to Concealment 650 Metric 652 * Metric Description: Proportion of concealed video frames to 653 which loss concealment (using Video Loss Concealment Method Type) 654 was applied comparing to the total number of frames during the 655 interval. 657 * Method of Measurement or Calculation: The metric is based on 658 measurements that are typically made at the time that a video 659 frame is decoded and rendered for playout. This metric is 660 calculated by dividing the number of frames to which loss 661 concealment (using Video Loss Concealment Method Type) was applied 662 by the total number of frames. It is equivalent to multiplying the 663 result of the division by 256, limiting the maximum value to 255 664 (to avoid overflow), and taking the integer part. 666 * Units of Measurement: This metric is expressed as a fixed point 667 number with the binary point at the left edge of the field. 669 * Measurement Point(s) with Potential Measurement Domain: It is 670 measured at the receiving end of the RTP stream. 672 * Measurement Timing: See paragraph 1 of Section 4. 674 * Use and Applications: These metrics are applicable to video 675 applications of RTP and the video component of Audio/Video 676 applications in which packet loss concealment mechanisms are 677 incorporated into the receiving endpoint to mitigate the impact of 678 network impairments on QoE. 680 Authors' Addresses 682 Rachel Huang 683 Huawei 684 101 Software Avenue, Yuhua District 685 Nanjing 210012 686 China 688 EMail: rachel.huang@huawei.com 690 Alan Clark 691 Telchemy Incorporated 692 2905 Premiere Parkway, Suite 280 693 Duluth, GA 30097 694 USA 696 Email: alan.d.clark@telchemy.com