idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-video-lc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7294], [RFC3611]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 271 has weird spacing: '...ired by trans...' -- The document date (July 6, 2015) is 3215 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6709' is mentioned on line 342, but not defined == Unused Reference: 'RFC4566' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'RFC5105' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'RFC4588' is defined on line 451, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Downref: Normative reference to an Informational RFC: RFC 7201 ** Downref: Normative reference to an Informational RFC: RFC 7202 Summary: 4 errors (**), 0 flaws (~~), 6 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: January 7, 2016 Telchemy 6 July 6, 2015 8 RTCP XR Report Block for Loss Concealment Metrics Reporting on 9 Video Applications 10 draft-ietf-xrblock-rtcp-xr-video-lc-01 12 Abstract 14 This draft defines a new video loss concealment block type to augment 15 those defined in [RFC3611] and [RFC7294] for use in a range of RTP 16 video applications. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1 RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . . 3 58 1.2 Performance Metrics Framework . . . . . . . . . . . . . . . 3 59 1.3 Applicability . . . . . . . . . . . . . . . . . . . . . . . 3 60 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3 Video Loss Concealment Methods . . . . . . . . . . . . . . . . 4 62 4. Video Loss Concealment Report Block . . . . . . . . . . . . . 5 63 5 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . . 8 65 5.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . . 8 66 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 67 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 68 7.1 New RTCP XR Block Type Value . . . . . . . . . . . . . . . . 9 69 7.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 9 70 7.3 Contact Information for registrations . . . . . . . . . . . 9 71 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 72 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 9.1 Normative References . . . . . . . . . . . . . . . . . . . 10 74 9.2 Informative References . . . . . . . . . . . . . . . . . . 11 75 Appendix A. Metrics Represented Using the Template from RFC 6390 . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 78 1 Introduction 80 Multimedia applications often suffer from packet losses in IP 81 networks. In order to get a reasonable degree of quality in case of 82 packet losses, it is necessary to have loss concealment mechanisms at 83 the decoder. Video loss concealment is a range of techniques to mask 84 the effects of packet loss in video communications. 86 In some applications, reporting the information of receivers applying 87 video loss concealment could give monitors or senders useful 88 information on application QoE. One example is no-reference video 89 quality evaluation. Video probes located upstream from the video 90 endpoint or terminal may not see loss occurring between the probe and 91 the endpoint, and may also not be fully aware of the specific loss 92 concealment methods being dynamically applied by the video endpoint. 93 Evaluating error concealment is important in the circumstance in 94 estimating the subjective impact of impairments. 96 This draft defines one new video loss concealment block type to 97 augment those defined in [RFC3611] and [RFC7294] for use in a range 98 of RTP video applications. The metrics defined in this draft belong 99 to the class of transport-related terminal metrics defined in 100 [RFC6792]. 102 1.1 RTCP and RTCP XR Reports 104 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 105 defines an extensible structure for reporting using an RTCP Extended 106 Report (XR). This draft defines a new Extended Report block that MUST 107 be used as defined in [RFC3550] and [RFC3611]. 109 1.2 Performance Metrics Framework 111 The Performance Metrics Framework [RFC6390] provides guidance on the 112 definition and specification of performance metrics. The RTP 113 Monitoring Architectures [RFC6792] provides guidelines for reporting 114 block format using RTCP XR. The XR block type described in this 115 document are in accordance with the guidelines in [RFC6390] and 116 [RFC6792]. 118 1.3 Applicability 120 These metrics are applicable to video applications of RTP and the 121 video component of Audio/Video applications in which packet loss 122 concealment mechanisms are incorporated into the receiving endpoint 123 to mitigate the impact of network impairments on QoE. For example, in 124 an IPTV system Set Top Boxes could use this RTCP XR block to report 125 loss and loss concealment metrics to an IPTV management system to 126 enable the service provider to monitor the quality of the IPTV 127 service being delivered to end users. 129 2 Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [KEYWORDS]. 135 3 Video Loss Concealment Methods 137 Video loss concealment mechanisms can be classified into 4 types as 138 follow: 140 a) Frame freeze 142 The impaired video frame is not displayed, instead, the previously 143 displayed frame is frozen for the duration of the loss event. 145 b) Inter-frame extrapolation 147 If an area of the video frame is damaged by loss, the same area from 148 the previous frame(s) can be used to estimate what the missing pixels 149 would have been. This can work well in a scene with no motion but can 150 be very noticeable if there is significant movement from one frame to 151 another. Simple decoders may simply re-use the pixels that were in 152 the missing area while more complex decoders may try to use several 153 frames to do a more complex extrapolation. Another example of a 154 sophisticated form of inter-frame repair is to estimate the motion of 155 the damaged region based on the motion of surrounding regions, and 156 use that to select what part of the previous frame to use for repair. 158 c) Interpolation 160 A decoder may user the undamaged pixels in the video frame to 161 estimate what the missing block of pixels should have. 163 d) Error Resilient Encoding 165 The sender may encode the message in a redundant way so that receiver 166 can correct errors using the redundant information. The redundant 167 data useful for error resiliency performed at the decoder can be 168 embedded into the compressed image/video bitstream. For example, the 169 encoder may select a crucial area of an original video frame, extract 170 some important characteristics of this area as the redundant 171 information, e.g., redundant motion vector of the first macroblock in 172 a slice of this area and redundant motion vector difference of other 173 macroblocks in this slice of this area, and imperceptibly embed them 174 into other parts of the video frame sent in a different RTP packet or 175 in the next frame, e.g., other slices of this area. FEC is also 176 another error resilient method. 178 In this document, we differentiate between frame freeze and the other 179 3 concealment mechanisms described. 181 4. Video Loss Concealment Report Block 183 This block reports the video loss concealment metrics to complement 184 the audio metrics defined in [RFC7294]. The report block SHOULD be in 185 conjunction with the information from the Measurement Information 186 Block [RFC6776]. Instances of this metrics block refer by SSRC to the 187 separate auxiliary Measurement Information Block [RFC6776]. This 188 metrics block relies on the measurement period in the Measurement 189 Information Block indicating the span of the report and SHOULD be 190 sent in the same compound RTCP packet as the Measurement Information 191 Block. If the measurement period is not received in the same compound 192 RTCP packet as this metric block, this metric block MUST be 193 discarded. It should be noted that the metrics in this report block 194 are based on measurements that are typically made at the time that a 195 video frame is decoded and rendered for playout. The metrics in this 196 block MUST be measured at a consistent point. 198 The video loss concealment report block has the following format: 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | BT=VLC | I | V | RSV | block length | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | SSRC of Source | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Impaired Duration | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Concealed Duration | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Mean Frame Freeze Duration (optional) | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | MIFP | MCFP | FFSC | Reserved | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Figure 1: Format for the Video Loss Concealment Report Block 218 Block Type (BT): 8 bits 219 A Video Loss Concealment Report Block is identified by the 220 constant VLC. 222 [Note to RFC Editor: Please replace VLC with the IANA provided 223 RTCP XR block type for this block.] 225 Interval Metric Flag (I): 2 bits 227 This field indicates whether the reported metric is an interval, 228 cumulative, or sampled metric [RFC6792]: 230 I=10: Interval Duration - the reported value applies to the 231 most recent measurement interval duration between successive 232 metrics reports. 234 I=11: Cumulative Duration - the reported value applies to the 235 accumulation period characteristic of cumulative measurements. 237 I=01: Sampled Value - this value MUST NOT be used for this 238 block type. 240 I=00: Reserved. 242 Video Loss Concealment Method Type (V): 2 bits 244 This field is used to identify the video loss concealment method 245 type used at the receiver. Each bit indicates one method type, as 246 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 block length: 16 bits 260 This field is in accordance with the definition in [RFC3611]. In 261 this report block, it MUST be set to 6 when V=10 and be set to 5 262 when V=11. The block MUST be discarded if the block length is set 263 to a different value. 265 SSRC of source: 32 bits 266 As defined in Section 4.1 of [RFC3611]. 268 Impaired Duration: 32 bits 270 The total time length, expressed in units of RTP timestamp, of 271 video impaired by transmission loss before applying any loss 272 concealment methods. 274 Two values are reserved: A value of 0xFFFFFFFE indicates out of 275 range (that is, a measured value exceeding 0xFFFFFFFD) and a value 276 of 0xFFFFFFFF indicates that the measurement is unavailable. 278 Concealed Duration: 32 bits 280 The total time length, expressed in units of RTP timestamp, of 281 concealed damaged video pictures on which loss concealment method 282 corresponding to V is applied. 284 Two values are reserved: A value of 0xFFFFFFFE indicates out of 285 range (that is, a measured value exceeding 0xFFFFFFFD) and a value 286 of 0xFFFFFFFF indicates that the measurement is unavailable. 288 Mean Frame Freeze Duration: 32 bits 290 Mean Frame Freeze Duration is the mean duration, expressed in 291 units of RTP timestamp, of the frame freeze events. The value of 292 Mean Frame Freeze Duration shall be calculated by summing the 293 total duration of all frame freeze events and dividing by the 294 number of events. This metric is optional. It only exists 295 whenV=10. 297 Mean Impaired Frame Proportion (MIFP): 8 bits 299 Mean Impaired Frame Proportion is the mean proportion of each 300 video frame impaired by loss before applying any loss concealment 301 method during the interval, expressed as a fixed point number with 302 the binary point at the left edge of the field. It is calculated 303 by summing the impaired proportion of each video frame and 304 dividing by the number of frames during this period. The impaired 305 proportion of each video frame is obtained by dividing the number 306 of missing macroblocks from this video frame by the total 307 macroblock number of the video frame, which is equivalent to 308 taking the integer part after multiplying the fraction by 256. If 309 a video frame is totally lost, a value of 0xFF shall be used for 310 the frame when calculating the mean value. 312 Mean Concealed Frame Proportion (MCFP): 8 bits 313 Mean Concealed Frame Proportion is the mean proportion of each 314 video frame to which loss concealment (using V) was applied during 315 the interval, expressed as a fixed point number with the binary 316 point at the left edge of the field. It is calculated by summing 317 the concealed proportion of each video frame and dividing by the 318 number of frames during this period. The concealed proportion of 319 each video frame is obtained by dividing the number of concealed 320 macroblocks from this video frame by the total macroblock number 321 of the video frame, which is equivalent to taking the integer part 322 after multiplying the fraction by 256. If a lost video frame is 323 totally concealed, a value of 0xFF and if there are no concealed 324 macroblocks, a value of 0, shall be used for the frame when 325 calculating the mean value. 327 Fraction of Frames Subject to Concealment (FFSC): 8 bits 329 Fraction of Frames Subject to Concealment is calculated by 330 dividing the number of frames to which loss concealment (using V) 331 was applied by the total number of frames and expressing this 332 value as a fixed point number with the binary point at the left 333 edge of the field. It is equivalent to taking the integer part 334 after multiplying the fraction by 256. A value of 0 indicates that 335 there were no concealed frame and a value of 0xFF indicates that 336 the frames in the entire measurement interval are all concealed. 338 Reserved: 8 bits 340 These bits are reserved for future use. They MUST be set to zero 341 by senders and ignored by receivers (see Section 4.2 of 342 [RFC6709]). 344 5 SDP Signaling 346 [RFC3611] defines the use of SDP (Session Description Protocol) for 347 signaling the use of RTCP XR blocks. However XR blocks MAY be used 348 without prior signaling (see section 5 of [RFC3611]). 350 5.1 SDP rtcp-xr-attrib Attribute Extension 352 This session augments the SDP attribute "rtcp-xr" defined in Section 353 5.1 of [RFC3611] by providing an additional value of "xr-format" to 354 signal the use of the report block defined in this document. 356 xr-format =/ xr-vlc-block 358 xr-vlc-block = "video-loss-concealment" 360 5.2 Offer/Answer Usage 361 When SDP is used in offer-answer context, the SDP Offer/Answer usage 362 defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters 363 applies. For detailed usage of Offer/Answer for unilateral 364 parameter, refer to section 5.2 of [RFC3611]. 366 6 Security Considerations 368 It is believed that this RTCP XR block introduces no new security 369 considerations beyond those described in [RFC3611]. This block does 370 not provide per-packet statistics, so the risk to confidentially 371 documented in Section 7, paragraph 3 of [RFC3611] does not apply. 373 An attacker may put incorrect information in the Video Loss 374 Concealment reports, which will be affect the estimation of video 375 loss concealment mechanisms performance and QoE of users. 376 Implementers should consider the guidance in [RFC7202] for using 377 appropriate security mechanisms, i.e., where security is a concern, 378 the implementation should apply encryption and authentication to the 379 report block. For example, this can be achieved by using the AVPF 380 profile together with the Secure RTP profile as defined in [RFC3711]; 381 an appropriate combination of the two profiles (an "SAVPF") is 382 specified in [RFC5124]. However, other mechanisms also exist 383 (documented in [RFC7201]) and might be more suitable. 385 7 IANA Considerations 387 New block types for RTCP XR are subject to IANA registration. For 388 general guidelines on IANA considerations for RTCP XR, refer to 389 [RFC3611]. 391 7.1 New RTCP XR Block Type Value 393 This document assigns the block type value VLC in the IANA "RTP 394 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 395 the "Video Loss Concealment Metrics Report Block". 397 [Note to RFC Editor: please replace VLC with the IANA provided RTCP 398 XR block type for this block.] 400 7.2 New RTCP XR SDP Parameter 402 This document also registers a new parameter "video-loss-concealment" 403 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 404 Description Protocol (SDP) Parameters Registry". 406 7.3 Contact Information for registrations 408 The following contact information is provided for all registrations 409 in this document: 411 Rachel Huang (rachel.huang@huawei.com) 413 101 Software Avenue, Yuhua District 414 Nanjing, Jiangsu 210012 415 China 417 8 Acknowledgements 419 The author would like to thank Colin Perkins, Roni Even for their 420 valuable comments. 422 9 References 424 9.1 Normative References 426 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, March 1997. 429 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 430 Jacobson, "RTP: A Transport Protocol for Real-Time 431 Applications", STD 64, RFC 3550, July 2003. 433 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 434 "RTP Control Protocol Extended Reports (RTCP XR)", 435 RFC 3611, November 2003. 437 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 438 Description Protocol", RFC 4566, July 2006. 440 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 441 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 442 RFC 3711, March 2004. 444 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 445 Real-time Transport Control Protocol (RTCP)-Based Feedback 446 (RTP/SAVPF)", RFC 5124, February 2008. 448 [RFC5105] Lendl, O., "ENUM Validation Token Format Definition", 449 RFC 5105, December 2007. 451 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 452 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 453 July 2006. 455 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 456 Reporting Using a Source Description (SDES) Item and an 457 RTCP Extended Report (XR) Block", RFC6776, October 2012. 459 [RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP 460 Sessions", RFC 7201, April 2014. 462 [RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP 463 Framework: Why RTP Does Not Mandate a Single Media 464 Security Solution", RFC 7202, April 2014. 466 [RFC7294] Clark, A., Zorn, G., Bi, C. and Q., Wu, "RTCP XR Report 467 Block for Concealment Metrics Reporting on Audio 468 Applications", April 2014. 470 9.2 Informative References 472 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 473 Performance Metric Development", BCP 170, RFC 6390, 474 October 2011. 476 [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the 477 RTP Monitoring Framework", RFC 6792, November 2012. 479 Appendix A. Metrics Represented Using the Template from RFC 6390 481 a. Video Impaired Duration Metric 483 * Metric Name: Video Impaired Duration Metric 485 * Metric Description: The total time length of video impaired by 486 transmission loss before applying any loss concealment methods. 488 * Method of Measurement or Calculation: The metric is based on 489 measurements that are typically made at the time that a video 490 frame is decoded and rendered for playout. 492 * Units of Measurement: This metric is expressed in units of RTP 493 timestamp. 495 * Measurement Point(s) with Potential Measurement Domain: It is 496 measured at the receiving end of the RTP stream. 498 * Measurement Timing: See paragraph 1 of Section 4. 500 * Use and Applications: The metric is applicable to video 501 applications of RTP and the video component of Audio/Video 502 applications in which packet loss concealment mechanisms are 503 incorporated into the receiving endpoint to mitigate the impact of 504 network impairments on QoE. 506 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 V 512 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 2 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 shall be 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 2 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 lost RTP packets from this video frame by the total packet 574 number of the video frame, which is equivalent to taking the 575 integer part after multiplying the loss fraction by 256. If a 576 video frame is totally lost, a value of 0xFF shall be used for the 577 frame when calculating the mean value. 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 2 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 V) was applied during the interval. 600 * Method of Measurement or Calculation: The metric is based on 601 measurements that are typically made at the time that a video 602 frame is decoded and rendered for playout. It is calculated by 603 summing the concealed proportion of each video frame and dividing 604 by the number of frames during this period. The concealed 605 proportion of each video frame is obtained by dividing the number 606 of concealed macroblocks from this video frame by the total 607 macroblock number of the video frame, which is equivalent to 608 taking the integer part after multiplying the fraction by 256. If 609 a lost video frame is totally concealed, a value of 0xFF and if 610 there are no concealed macroblocks, a value of 0, shall be used 611 for the frame when calculating the mean value. 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 2 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 V) was applied comparing to the 634 total number of frames during the interval. 636 * Method of Measurement or Calculation: The metric is based on 637 measurements that are typically made at the time that a video 638 frame is decoded and rendered for playout. This metric is 639 calculated by dividing the number of frames to which loss 640 concealment (using V) was applied by the total number of frames. 641 It is equivalent to taking the integer part after multiplying the 642 fraction by 256. A value of 0 indicates that there were no 643 concealed frame and a value of 0xFF indicates that the frames in 644 the entire measurement interval are all concealed. 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 2 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