idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-video-lc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7294], [RFC3611]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 197: '... the audio metrics defined in [RFC7294]. The report block MUST be sent...' RFC 2119 keyword, line 204: '...his metric block MUST be discarded at ...' RFC 2119 keyword, line 249: '...lue - this value MUST NOT be used for ...' RFC 2119 keyword, line 266: '... SHOULD be compounded together to...' RFC 2119 keyword, line 270: '... future use. They MUST be set to zero...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [KEYWORDS], but that reference does not seem to mention RFC 2119 either. -- The document date (September 11, 2015) is 3150 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: 'RFC3611' is mentioned on line 422, but not defined == Missing Reference: 'RFC3550' is mentioned on line 108, but not defined == Missing Reference: 'KEYWORDS' is mentioned on line 135, but not defined == Missing Reference: 'RFC6709' is mentioned on line 375, but not defined == Missing Reference: 'RFC3711' is mentioned on line 413, but not defined == Missing Reference: 'RFC5124' is mentioned on line 415, but not defined ** Downref: Normative reference to an Informational RFC: RFC 7201 ** Downref: Normative reference to an Informational RFC: RFC 7202 Summary: 5 errors (**), 0 flaws (~~), 7 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: March 14, 2016 Telchemy 6 September 11, 2015 8 RTCP XR Report Block for Loss Concealment Metrics Reporting on 9 Video Applications 10 draft-ietf-xrblock-rtcp-xr-video-lc-02 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. 16 This XR report block completes ones defined in [RFC3611] and 17 [RFC7294]. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . . 3 59 1.2 Performance Metrics Framework . . . . . . . . . . . . . . . 3 60 1.3 Applicability . . . . . . . . . . . . . . . . . . . . . . . 3 61 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3 Video Loss Concealment Methods . . . . . . . . . . . . . . . . 4 63 4 Video Loss Concealment Report Block . . . . . . . . . . . . . . 5 64 5 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . . 9 66 5.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . . 9 67 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 68 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 69 7.1 New RTCP XR Block Type Value . . . . . . . . . . . . . . . . 10 70 7.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 10 71 7.3 Contact Information for registrations . . . . . . . . . . . 10 72 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 73 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 9.1 Normative References . . . . . . . . . . . . . . . . . . . 10 75 9.2 Informative References . . . . . . . . . . . . . . . . . . 11 76 Appendix A. Metrics Represented Using the Template from RFC 6390 . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 79 1 Introduction 81 Multimedia applications often suffer from packet losses in IP 82 networks. In order to get a reasonable degree of quality in case of 83 packet losses, it is necessary to have loss concealment mechanisms at 84 the decoder. Video loss concealment is a range of techniques to mask 85 the effects of packet loss in video communications. 87 In some applications, reporting the information of receivers applying 88 video loss concealment could give monitors or senders useful 89 information on application QoE. One example is no-reference video 90 quality evaluation. Video probes located upstream from the video 91 endpoint or terminal may not see loss occurring between the probe and 92 the endpoint, and may also not be fully aware of the specific loss 93 concealment methods being dynamically applied by the video endpoint. 94 Evaluating error concealment is important in the circumstance in 95 estimating the subjective impact of impairments. 97 This draft defines one new video loss concealment block type to 98 augment those defined in [RFC3611] and [RFC7294] for use in a range 99 of RTP video applications. The metrics defined in this draft belong 100 to the class of transport-related terminal metrics defined in 101 [RFC6792]. 103 1.1 RTCP and RTCP XR Reports 105 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 106 defines an extensible structure for reporting using an RTCP Extended 107 Report (XR). This draft defines a new Extended Report block that is 108 used as defined in [RFC3550] and [RFC3611]. 110 1.2 Performance Metrics Framework 112 The Performance Metrics Framework [RFC6390] provides guidance on the 113 definition and specification of performance metrics. The RTP 114 Monitoring Architectures [RFC6792] provides guidelines for reporting 115 block format using RTCP XR. The XR block type described in this 116 document are in accordance with the guidelines in [RFC6390] and 117 [RFC6792]. 119 1.3 Applicability 121 These metrics are applicable to video applications the video 122 component of Audio/Video applications using RTP and applying packet 123 loss concealment mechanisms which are incorporated into the receiving 124 endpoint to mitigate the impact of network impairments on QoE. For 125 example, in an IPTV system Set Top Boxes could use this RTCP XR block 126 to report loss and loss concealment metrics to an IPTV management 127 system to enable the service provider to monitor the quality of the 128 IPTV service being delivered to end users. 130 2 Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [KEYWORDS]. 136 3 Video Loss Concealment Methods 138 Video loss concealment mechanisms can be classified into 4 types as 139 follow: 141 a) Frame freeze 143 The impaired video frame is not displayed, instead, the previously 144 displayed frame is frozen for the duration of the loss event. 146 b) Inter-frame extrapolation 148 If an area of the video frame is damaged by loss, the same area from 149 the previous frame(s) can be used to estimate what the missing pixels 150 would have been. This can work well in a scene with no motion but can 151 be very noticeable if there is significant movement from one frame to 152 another. Simple decoders can simply re-use the pixels that were in 153 the missing area while more complex decoders can try to use several 154 frames to do a more complex extrapolation. Another example of a 155 sophisticated form of inter-frame repair is to estimate the motion of 156 the damaged region based on the motion of surrounding regions, and 157 use that to select what part of the previous frame to use for repair. 158 Some important frames, such as IDR frames, may not depend on any 159 other frames and may be involved in a scene change. Using inter-frame 160 extrapolation method to conceal the loss of these frames may not 161 obtain a quite satisfactory result. 163 c) Interpolation 165 A decoder uses the undamaged pixels in the video frame to estimate 166 what the missing block of pixels should have. 168 d) Error Resilient Encoding 170 The sender encodes the message in a redundant way so that receiver 171 can correct errors using the redundant information.There are usually 172 two kinds of Error Resilient Encoding: One is that the redundant data 173 useful for error resiliency performed at the decoder can be embedded 174 into the compressed image/video bitstream. For example, the encoder 175 can select a crucial area of an original video frame, extract some 176 important characteristics of this area as the redundant information, 177 e.g., redundant motion vector of the first macroblock in a slice of 178 this area and redundant motion vector difference of other macroblocks 179 in this slice of this area, and imperceptibly embed them into other 180 parts of the video frame sent in a different RTP packet or in the 181 next frame, e.g., other slices of this area. The other is bit-block 182 level encoding, e.g., FEC. 184 Usually, methods b,c,d are deployed together to provide a 185 comprehensive loss concealment in some complex decoders, while method 186 a is relatively independent and may be only applied in some simple 187 decoders. Moreover, frame freeze method repairs video based on frames 188 while the other methods repair video based on fine-grained elements, 189 such as macroblock or bit-block, which will cause the measurement 190 metrics of frame freeze and the other methods slightly different. 191 Thus, In this document, we differentiate between frame freeze and the 192 other 3 concealment mechanisms described. 194 4 Video Loss Concealment Report Block 196 This block reports the video loss concealment metrics to complement 197 the audio metrics defined in [RFC7294]. The report block MUST be sent 198 in conjunction with the information from the Measurement Information 199 Block [RFC6776]. Instances of this metric block refer by SSRC to the 200 separate auxiliary Measurement Information Block [RFC6776]. This 201 metric block relies on the measurement period in the Measurement 202 Information Block indicating the span of the report. If the 203 measurement period is not received in the same compound RTCP packet 204 as this metric block, this metric block MUST be discarded at the 205 receiving side. The metrics in this report block are based on 206 measurements that are typically made at the time that a video frame 207 is decoded and rendered for playout. 209 The video loss concealment report block has the following format: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | BT=VLC | I | V | RSV | block length | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | SSRC of Source | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Impaired Duration | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Concealed Duration | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Mean Frame Freeze Duration (optional) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | MIFP | MCFP | FFSC | Reserved | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Figure 1: Format for the Video Loss Concealment Report Block 229 Block Type (BT): 8 bits 231 A Video Loss Concealment Report Block is identified by the 232 constant VLC. 234 [Note to RFC Editor: Please replace VLC with the IANA provided 235 RTCP XR block type for this block.] 237 Interval Metric Flag (I): 2 bits 239 This field indicates whether the reported metrics are interval, 240 cumulative, or sampled metrics [RFC6792]: 242 I=10: Interval Duration - the reported value applies to the 243 most recent measurement interval duration between successive 244 metrics reports. 246 I=11: Cumulative Duration - the reported value applies to the 247 accumulation period characteristic of cumulative measurements. 249 I=01: Sampled Value - this value MUST NOT be used for this 250 block type. 252 I=00: Reserved. 254 Video Loss Concealment Method Type (V): 2 bits 256 This field is used to identify the video loss concealment method 257 type used at the receiver. The value is defined as follow: 259 V=10 - Frame freeze 260 V=11 - Other Loss Concealment Method 261 V=01&00 - Reserved 263 If Frame freeze and other loss concealment method are used 264 together for the media stream, 2 report blocks, one with V=10 for 265 frame freeze and one with V=11 for other loss concealment method 266 SHOULD be compounded together to report the whole concealment 267 information. 269 RSV: 4 bits 270 These bits are reserved for future use. They MUST be set to zero 271 by senders and ignored by receivers (see Section 4.2 of 272 [RFC6709]). 274 block length: 16 bits 276 This field is in accordance with the definition in [RFC3611]. In 277 this report block, it MUST be set to 6 when V=10 and be set to 5 278 when V=11. The block MUST be discarded if the block length is set 279 to a different value. 281 SSRC of source: 32 bits 283 As defined in Section 4.1 of [RFC3611]. 285 Impaired Duration: 32 bits 287 The total time length, expressed in units of RTP timestamp from 288 the sending side of the reporting block, of video impaired by 289 transmission loss before applying any loss concealment methods. 291 Two values are reserved: A value of 0xFFFFFFFE indicates out of 292 range (that is, a measured value exceeding 0xFFFFFFFD) and a value 293 of 0xFFFFFFFF indicates that the measurement is unavailable. 295 Concealed Duration: 32 bits 297 The total time length, expressed in units of RTP timestamp from 298 the sending side of the reporting block, of concealed damaged 299 video pictures on which loss concealment method corresponding to 300 Video Loss Concealment Method Type is applied. 302 Two values are reserved: A value of 0xFFFFFFFE indicates out of 303 range (that is, a measured value exceeding 0xFFFFFFFD) and a value 304 of 0xFFFFFFFF indicates that the measurement is unavailable. 306 Mean Frame Freeze Duration: 32 bits 308 Mean Frame Freeze Duration is the mean duration, expressed in 309 units of RTP timestamp from the sending side of the reporting 310 block, of the frame freeze events. The value of Mean Frame Freeze 311 Duration is calculated by summing the total duration of all frame 312 freeze events and dividing by the number of events. This metric is 313 optional. It only exists when Video Loss Concealment Method 314 Type=10. 316 Mean Impaired Frame Proportion (MIFP): 8 bits 317 Mean Impaired Frame Proportion is the mean proportion of each 318 video frame impaired by loss before applying any loss concealment 319 method during the interval, expressed as a fixed point number with 320 the binary point at the left edge of the field. It is calculated 321 by summing the impaired proportion of each video frame and 322 dividing by the number of frames during this period. The impaired 323 proportion of each video frame is obtained by dividing the number 324 of missing macroblocks from this video frame by the total 325 macroblock number of the video frame, which is equivalent to 326 multiplying the result of the division by 256, limiting the 327 maximum value to 255 (to avoid overflow), and taking the integer 328 part. 330 If a video frame is totally lost, a value of 0xFF SHOULD be used 331 for the frame when calculating the mean value. 333 Mean Concealed Frame Proportion (MCFP): 8 bits 335 Mean Concealed Frame Proportion is the mean proportion of each 336 video frame to which loss concealment (depicted as "V" in the 337 definition of "Video Loss Concealment Method Type") was applied 338 during the interval, expressed as a fixed point number with the 339 binary point at the left edge of the field. It is calculated by 340 summing the concealed proportion of each video frame and dividing 341 by the number of frames during this period. The concealed 342 proportion of each video frame is obtained by dividing the number 343 of concealed macroblocks from this video frame by the total 344 macroblock number of the video frame, which is equivalent to 345 multiplying the result of the division by 256, limiting the 346 maximum value to 255 (to avoid overflow), and taking the integer 347 part. 349 If a lost video frame is totally concealed, a value of 0xFF and if 350 there are no concealed macroblocks, a value of 0, SHOULD be used 351 for the frame when calculating the mean value. For Video Loss 352 Concealment Method Type=10, each frame covered in the period of 353 frame freeze is considered to be totally concealed, which means a 354 value of 0xFF MUST be assigned. 356 Fraction of Frames Subject to Concealment (FFSC): 8 bits 358 Fraction of Frames Subject to Concealment is calculated by 359 dividing the number of frames to which loss concealment (using 360 Video Loss Concealment Method Type) was applied by the total 361 number of frames and expressing this value as a fixed point number 362 with the binary point at the left edge of the field. It is 363 equivalent to multiplying the result of the division by 256, 364 limiting the maximum value to 255 (to avoid overflow), and taking 365 the integer part. 367 A value of 0 indicates that there were no concealed frame and a 368 value of 0xFF indicates that the frames in the entire measurement 369 interval are all concealed. 371 Reserved: 8 bits 373 These bits are reserved for future use. They MUST be set to zero 374 by senders and ignored by receivers (see Section 4.2 of 375 [RFC6709]). 377 5 SDP Signaling 379 [RFC3611] defines the use of SDP (Session Description Protocol) for 380 signaling the use of RTCP XR blocks. 382 5.1 SDP rtcp-xr-attrib Attribute Extension 384 This session augments the SDP attribute "rtcp-xr" defined in Section 385 5.1 of [RFC3611] by providing an additional value of "xr-format" to 386 signal the use of the report block defined in this document. 388 xr-format =/ xr-vlc-block 390 xr-vlc-block = "vlc" 392 5.2 Offer/Answer Usage 394 When SDP is used in offer-answer context, the SDP Offer/Answer usage 395 defined in section 5.2 of [RFC3611] for unilateral "rtcp-xr" 396 attribute parameters applies. For detailed usage of Offer/Answer for 397 unilateral parameter, refer to section 5.2 of [RFC3611]. 399 6 Security Considerations 401 It is believed that this RTCP XR block introduces no new security 402 considerations beyond those described in [RFC3611]. This block does 403 not provide per-packet statistics, so the risk to confidentially 404 documented in Section 7, paragraph 3 of [RFC3611] does not apply. 406 An attacker is likely to put incorrect information in the Video Loss 407 Concealment reports, which will affect the estimation of video loss 408 concealment mechanisms performance and QoE of users. Implementers 409 SHOULD consider the guidance in [RFC7202] for using appropriate 410 security mechanisms, i.e., where security is a concern, the 411 implementation SHOULD apply encryption and authentication to the 412 report block. For example, this can be achieved by using the AVPF 413 profile together with the Secure RTP profile as defined in [RFC3711]; 414 an appropriate combination of the two profiles (an "SAVPF") is 415 specified in [RFC5124]. However, other mechanisms also exist 416 (documented in [RFC7201]) and might be more suitable. 418 7 IANA Considerations 420 New block types for RTCP XR are subject to IANA registration. For 421 general guidelines on IANA considerations for RTCP XR, please refer 422 to [RFC3611]. 424 7.1 New RTCP XR Block Type Value 426 This document assigns the block type value VLC in the IANA "RTP 427 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 428 the "Video Loss Concealment Metric Report Block". 430 [Note to RFC Editor: please replace VLC with the IANA provided RTCP 431 XR block type for this block.] 433 7.2 New RTCP XR SDP Parameter 435 This document also registers a new parameter "video-loss-concealment" 436 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 437 Description Protocol (SDP) Parameters Registry". 439 7.3 Contact Information for registrations 441 The contact information for the registration is: 443 RAI Area Directors 445 rai-ads@tools.ietf.org 447 8 Acknowledgements 449 The author would like to thank Colin Perkins, Roni Even for their 450 valuable comments. 452 9 References 454 9.1 Normative References 456 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 457 Reporting Using a Source Description (SDES) Item and an 458 RTCP Extended Report (XR) Block", RFC6776, October 2012. 460 [RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP 461 Sessions", RFC 7201, April 2014. 463 [RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP 464 Framework: Why RTP Does Not Mandate a Single Media 465 Security Solution", RFC 7202, April 2014. 467 [RFC7294] Clark, A., Zorn, G., Bi, C. and Q., Wu, "RTCP XR Report 468 Block for Concealment Metrics Reporting on Audio 469 Applications", April 2014. 471 9.2 Informative References 473 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 474 Performance Metric Development", BCP 170, RFC 6390, 475 October 2011. 477 [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the 478 RTP Monitoring Framework", RFC 6792, November 2012. 480 Appendix A. Metrics Represented Using the Template from RFC 6390 482 a. Video Impaired Duration Metric 484 * Metric Name: Video Impaired Duration Metric 486 * Metric Description: The total time length of video impaired by 487 transmission loss before applying any loss concealment methods. 489 * Method of Measurement or Calculation: The metric is based on 490 measurements that are typically made at the time that a video 491 frame is decoded and rendered for playout. 493 * Units of Measurement: This metric is expressed in units of RTP 494 timestamp. 496 * Measurement Point(s) with Potential Measurement Domain: It is 497 measured at the receiving end of the RTP stream. 499 * Measurement Timing: See paragraph 1 of Section 4. 501 * Use and Applications: The metric is applicable to video 502 applications of RTP and the video component of Audio/Video 503 applications in which packet loss concealment mechanisms are 504 applied to the receiving endpoint to mitigate the impact of 505 network impairments on QoE. 507 b. Video Concealed Duration Metric 508 * Metric Name: Video Concealed Duration Metric 510 * Metric Description: The total time length of concealed damaged 511 video pictures on which loss concealment method corresponding to 512 Video Loss Concealment Method Type is applied. 514 * Method of Measurement or Calculation: The metric is based on 515 measurements that are typically made at the time that a video 516 frame is decoded and rendered for playout. 518 * Units of Measurement: This metric is expressed in units of RTP 519 timestamp. 521 * Measurement Point(s) with Potential Measurement Domain: It is 522 measured at the receiving end of the RTP stream. 524 * Measurement Timing: See paragraph 1 of Section 4. 526 * Use and Applications: These metrics are applicable to video 527 applications of RTP and the video component of Audio/Video 528 applications in which packet loss concealment mechanisms are 529 incorporated into the receiving endpoint to mitigate the impact of 530 network impairments on QoE. 532 c. Mean Video Frame Freeze Duration Metric 534 * Metric Name: Mean Video Frame Freeze Duration Metric 536 * Metric Description: The mean duration of the frame freeze 537 events. 539 * Method of Measurement or Calculation: The metric is based on 540 measurements that are typically made at the time that a video 541 frame is decoded and rendered for playout. The metric is 542 calculated by summing the total duration of all frame freeze 543 events and dividing by the number of events. 545 * Units of Measurement: This metric is expressed in units of RTP 546 timestamp. 548 * Measurement Point(s) with Potential Measurement Domain: It is 549 measured at the receiving end of the RTP stream. 551 * Measurement Timing: See paragraph 1 of Section 4. 553 * Use and Applications: These metrics are applicable to video 554 applications of RTP and the video component of Audio/Video 555 applications in which packet loss concealment mechanisms are 556 incorporated into the receiving endpoint to mitigate the impact of 557 network impairments on QoE. 559 d. Mean Impaired Video Frame Proportion Metric 561 * Metric Name: Mean Impaired Video Frame Proportion Metric 563 * Metric Description: Mean proportion of each video frame impaired 564 by loss before applying any loss concealment method during the 565 interval. 567 * Method of Measurement or Calculation: The metric is based on 568 measurements that are typically made at the time that a video 569 frame is decoded and rendered for playout. It is calculated by 570 summing the impaired proportion of each video frame and dividing 571 by the number of frames during this period. The impaired 572 proportion of each video frame is obtained by dividing the number 573 of missing macroblocks from this video frame by the total 574 macroblock number of the video frame, which is equivalent to 575 multiplying the result of the division by 256, limiting the 576 maximum value to 255 (to avoid overflow), and taking the integer 577 part. 579 * Units of Measurement: This metric is expressed as a fixed point 580 number with the binary point at the left edge of the field. 582 * Measurement Point(s) with Potential Measurement Domain: It is 583 measured at the receiving end of the RTP stream. 585 * Measurement Timing: See paragraph 1 of Section 4. 587 * Use and Applications: These metrics are applicable to video 588 applications of RTP and the video component of Audio/Video 589 applications in which packet loss concealment mechanisms are 590 incorporated into the receiving endpoint to mitigate the impact of 591 network impairments on QoE. 593 e. Mean Concealed Video Frame Proportion Metric 595 * Metric Name: Mean Concealed Video Frame Proportion Metric 597 * Metric Description: Mean proportion of each video frame to which 598 loss concealment (using Video Loss Concealment Method Type) was 599 applied during the interval. 601 * Method of Measurement or Calculation: The metric is based on 602 measurements that are typically made at the time that a video 603 frame is decoded and rendered for playout. It is calculated by 604 summing the concealed proportion of each video frame and dividing 605 by the number of frames during this period. The concealed 606 proportion of each video frame is obtained by dividing the number 607 of concealed macroblocks from this video frame by the total 608 macroblock number of the video frame, which is equivalent to 609 multiplying the result of the division by 256, limiting the 610 maximum value to 255 (to avoid overflow), and taking the integer 611 part. 613 * Units of Measurement: This metric is expressed as a fixed point 614 number with the binary point at the left edge of the field. 616 * Measurement Point(s) with Potential Measurement Domain: It is 617 measured at the receiving end of the RTP stream. 619 * Measurement Timing: See paragraph 1 of Section 4. 621 * Use and Applications: These metrics are applicable to video 622 applications of RTP and the video component of Audio/Video 623 applications in which packet loss concealment mechanisms are 624 incorporated into the receiving endpoint to mitigate the impact of 625 network impairments on QoE. 627 f. Fraction of Video Frames Subject to Concealment Metric 629 * Metric Name: Fraction of Video Frames Subject to Concealment 630 Metric 632 * Metric Description: Proportion of concealed video frames to 633 which loss concealment (using Video Loss Concealment Method Type) 634 was applied comparing to the total number of frames during the 635 interval. 637 * Method of Measurement or Calculation: The metric is based on 638 measurements that are typically made at the time that a video 639 frame is decoded and rendered for playout. This metric is 640 calculated by dividing the number of frames to which loss 641 concealment (using Video Loss Concealment Method Type) was applied 642 by the total number of frames. It is equivalent to multiplying the 643 result of the division by 256, limiting the maximum value to 255 644 (to avoid overflow), and taking the integer part. 646 * Units of Measurement: This metric is expressed as a fixed point 647 number with the binary point at the left edge of the field. 649 * Measurement Point(s) with Potential Measurement Domain: It is 650 measured at the receiving end of the RTP stream. 652 * Measurement Timing: See paragraph 1 of Section 4. 654 * Use and Applications: These metrics are applicable to video 655 applications of RTP and the video component of Audio/Video 656 applications in which packet loss concealment mechanisms are 657 incorporated into the receiving endpoint to mitigate the impact of 658 network impairments on QoE. 660 Authors' Addresses 662 Rachel Huang 663 Huawei 664 101 Software Avenue, Yuhua District 665 Nanjing 210012 666 China 668 EMail: rachel.huang@huawei.com 670 Alan Clark 671 Telchemy Incorporated 672 2905 Premiere Parkway, Suite 280 673 Duluth, GA 30097 674 USA 676 Email: alan.d.clark@telchemy.com