Skip to main content

RTCP XR Report Block for Loss Concealment Metrics Reporting on Video Applications
draft-ietf-xrblock-rtcp-xr-video-lc-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7867.
Authors Rachel Huang , Alan Clark
Last updated 2015-10-21 (Latest revision 2015-09-11)
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Dan Romascanu
IESG IESG state Became RFC 7867 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to "Dan Romascanu" <dromasca@avaya.com>
draft-ietf-xrblock-rtcp-xr-video-lc-02
XRBLOCK                                                         R. Huang
INTERNET-DRAFT                                                    Huawei
Intended Status: Standards Track                                A. Clark
Expires: March 14, 2016                                         Telchemy
                                                      September 11, 2015

    RTCP XR Report Block for Loss Concealment Metrics Reporting on 
                           Video Applications
                 draft-ietf-xrblock-rtcp-xr-video-lc-02

Abstract

   This document defines a new RTCP XR Report Block that allows the
   reporting of loss concealment metrics for video applications of RTP.
   This XR report block completes ones defined in [RFC3611] and
   [RFC7294].

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
 

<Huang, et al.>          Expires March 14, 2016                 [Page 1]
INTERNET DRAFT       <Video LC Metrics for RTCP XR>   September 11, 2015

   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1 RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . .  3
     1.2 Performance Metrics Framework  . . . . . . . . . . . . . . .  3
     1.3 Applicability  . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3  Video Loss Concealment Methods  . . . . . . . . . . . . . . . .  4
   4  Video Loss Concealment Report Block . . . . . . . . . . . . . .  5
   5 SDP Signaling  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . .  9
     5.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . .  9
   6 Security Considerations  . . . . . . . . . . . . . . . . . . . .  9
   7 IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 10
     7.1 New RTCP XR Block Type Value . . . . . . . . . . . . . . . . 10
     7.2 New RTCP XR SDP Parameter  . . . . . . . . . . . . . . . . . 10
     7.3 Contact Information for registrations  . . . . . . . . . . . 10
   8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
   9  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1  Normative References  . . . . . . . . . . . . . . . . . . . 10
     9.2  Informative References  . . . . . . . . . . . . . . . . . . 11
   Appendix A. Metrics Represented Using the Template from RFC 6390 . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

 

<Huang, et al.>          Expires March 14, 2016                 [Page 2]
INTERNET DRAFT       <Video LC Metrics for RTCP XR>   September 11, 2015

1  Introduction

   Multimedia applications often suffer from packet losses in IP
   networks. In order to get a reasonable degree of quality in case of
   packet losses, it is necessary to have loss concealment mechanisms at
   the decoder. Video loss concealment is a range of techniques to mask
   the effects of packet loss in video communications. 

   In some applications, reporting the information of receivers applying
   video loss concealment could give monitors or senders useful
   information on application QoE. One example is no-reference video
   quality evaluation. Video probes located upstream from the video
   endpoint or terminal may not see loss occurring between the probe and
   the endpoint, and may also not be fully aware of the specific loss
   concealment methods being dynamically applied by the video endpoint.
   Evaluating error concealment is important in the circumstance in
   estimating the subjective impact of impairments.  

   This draft defines one new video loss concealment block type to
   augment those defined in [RFC3611] and [RFC7294] for use in a range
   of RTP video applications. The metrics defined in this draft belong
   to the class of transport-related terminal metrics defined in
   [RFC6792].

1.1 RTCP and RTCP XR Reports

   The use of RTCP for reporting is defined in [RFC3550]. [RFC3611]
   defines an extensible structure for reporting using an RTCP Extended
   Report (XR). This draft defines a new Extended Report block that is
   used as defined in [RFC3550] and [RFC3611].

1.2 Performance Metrics Framework

   The Performance Metrics Framework [RFC6390] provides guidance on the
   definition and specification of performance metrics. The RTP
   Monitoring Architectures [RFC6792] provides guidelines for reporting
   block format using RTCP XR. The XR block type described in this
   document are in accordance with the guidelines in [RFC6390] and
   [RFC6792].

1.3 Applicability

   These metrics are applicable to video applications the video
   component of Audio/Video applications using RTP and applying packet
   loss concealment mechanisms which are incorporated into the receiving
   endpoint to mitigate the impact of network impairments on QoE. For
   example, in an IPTV system Set Top Boxes could use this RTCP XR block
   to report loss and loss concealment metrics to an IPTV management
 

<Huang, et al.>          Expires March 14, 2016                 [Page 3]
INTERNET DRAFT       <Video LC Metrics for RTCP XR>   September 11, 2015

   system to enable the service provider to monitor the quality of the
   IPTV service being delivered to end users.

2  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [KEYWORDS].

3  Video Loss Concealment Methods

   Video loss concealment mechanisms can be classified into 4 types as
   follow:

   a) Frame freeze

   The impaired video frame is not displayed, instead, the previously
   displayed frame is frozen for the duration of the loss event.

   b) Inter-frame extrapolation

   If an area of the video frame is damaged by loss, the same area from
   the previous frame(s) can be used to estimate what the missing pixels
   would have been. This can work well in a scene with no motion but can
   be very noticeable if there is significant movement from one frame to
   another. Simple decoders can simply re-use the pixels that were in
   the missing area while more complex decoders can try to use several
   frames to do a more complex extrapolation. Another example of a
   sophisticated form of inter-frame repair is to estimate the motion of
   the damaged region based on the motion of surrounding regions, and
   use that to select what part of the previous frame to use for repair.
   Some important frames, such as IDR frames, may not depend on any
   other frames and may be involved in a scene change. Using inter-frame
   extrapolation method to conceal the loss of these frames may not
   obtain a quite satisfactory result.

   c) Interpolation

   A decoder uses the undamaged pixels in the video frame to estimate
   what the missing block of pixels should have.

   d) Error Resilient Encoding

   The sender encodes the message in a redundant way so that receiver
   can correct errors using the redundant information.There are usually
   two kinds of Error Resilient Encoding: One is that the redundant data
   useful for error resiliency performed at the decoder can be embedded
   into the compressed image/video bitstream. For example, the encoder
 

<Huang, et al.>          Expires March 14, 2016                 [Page 4]
INTERNET DRAFT       <Video LC Metrics for RTCP XR>   September 11, 2015

   can select a crucial area of an original video frame, extract some
   important characteristics of this area as the redundant information,
   e.g., redundant motion vector of the first macroblock in a slice of
   this area and redundant motion vector difference of other macroblocks
   in this slice of this area, and imperceptibly embed them into other
   parts of the video frame sent in a different RTP packet or in the
   next frame, e.g., other slices of this area. The other is bit-block
   level encoding, e.g., FEC.

   Usually, methods b,c,d are deployed together to provide a
   comprehensive loss concealment in some complex decoders, while method
   a is relatively independent and may be only applied in some simple
   decoders. Moreover, frame freeze method repairs video based on frames
   while the other methods repair video based on fine-grained elements,
   such as macroblock or bit-block, which will cause the measurement
   metrics of frame freeze and the other methods slightly different.
   Thus, In this document, we differentiate between frame freeze and the
   other 3 concealment mechanisms described.

4  Video Loss Concealment Report Block

   This block reports the video loss concealment metrics to complement
   the audio metrics defined in [RFC7294]. The report block MUST be sent
   in conjunction with the information from the Measurement Information
   Block [RFC6776]. Instances of this metric block refer by SSRC to the
   separate auxiliary Measurement Information Block [RFC6776]. This
   metric block relies on the measurement period in the Measurement
   Information Block indicating the span of the report. If the
   measurement period is not received in the same compound RTCP packet
   as this metric block, this metric block MUST be discarded at the
   receiving side. The metrics in this report block are based on
   measurements that are typically made at the time that a video frame
   is decoded and rendered for playout.

   The video loss concealment report block has the following format:

    0               1               2               3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    BT=VLC     | I | V |  RSV  |       block length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SSRC of Source                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Impaired Duration                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Concealed Duration                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Mean Frame Freeze Duration (optional)        |
 

<Huang, et al.>          Expires March 14, 2016                 [Page 5]
INTERNET DRAFT       <Video LC Metrics for RTCP XR>   September 11, 2015

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    MIFP       |    MCFP       |     FFSC      |     Reserved  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 1: Format for the Video Loss Concealment Report Block

   Block Type (BT): 8 bits

      A Video Loss Concealment Report Block is identified by the
      constant VLC.

      [Note to RFC Editor: Please replace VLC with the IANA provided
      RTCP XR block type for this block.]

   Interval Metric Flag (I): 2 bits

      This field indicates whether the reported metrics are interval,
      cumulative, or sampled metrics [RFC6792]:

         I=10: Interval Duration - the reported value applies to the
         most recent measurement interval duration between successive
         metrics reports.

         I=11: Cumulative Duration - the reported value applies to the
         accumulation period characteristic of cumulative measurements.

         I=01: Sampled Value - this value MUST NOT be used for this
         block type.

         I=00: Reserved.

   Video Loss Concealment Method Type (V): 2 bits

      This field is used to identify the video loss concealment method
      type used at the receiver. The value is defined as follow:

        V=10 - Frame freeze
        V=11 - Other Loss Concealment Method
        V=01&00 - Reserved

      If Frame freeze and other loss concealment method are used
      together for the media stream, 2 report blocks, one with V=10 for
      frame freeze and one with V=11 for other loss concealment method
      SHOULD be compounded together to report the whole concealment
      information.

   RSV: 4 bits

 

<Huang, et al.>          Expires March 14, 2016                 [Page 6]
INTERNET DRAFT       <Video LC Metrics for RTCP XR>   September 11, 2015

      These bits are reserved for future use.  They MUST be set to zero
      by senders and ignored by receivers (see Section 4.2 of
      [RFC6709]).

   block length: 16 bits

      This field is in accordance with the definition in [RFC3611]. In
      this report block, it MUST be set to 6 when V=10 and be set to 5
      when V=11. The block MUST be discarded if the block length is set
      to a different value.

   SSRC of source: 32 bits

      As defined in Section 4.1 of [RFC3611].

   Impaired Duration: 32 bits

      The total time length, expressed in units of RTP timestamp from
      the sending side of the reporting block, of video impaired by 
      transmission loss before applying any loss concealment methods. 

      Two values are reserved: A value of 0xFFFFFFFE indicates out of
      range (that is, a measured value exceeding 0xFFFFFFFD) and a value
      of 0xFFFFFFFF indicates that the measurement is unavailable.

   Concealed Duration: 32 bits

      The total time length, expressed in units of RTP timestamp from
      the sending side of the reporting block, of concealed damaged
      video pictures on which loss concealment method corresponding to
      Video Loss Concealment Method Type is applied.

      Two values are reserved: A value of 0xFFFFFFFE indicates out of
      range (that is, a measured value exceeding 0xFFFFFFFD) and a value
      of 0xFFFFFFFF indicates that the measurement is unavailable.

   Mean Frame Freeze Duration: 32 bits

      Mean Frame Freeze Duration is the mean duration, expressed in
      units of RTP timestamp from the sending side of the reporting
      block, of the frame freeze events. The value of Mean Frame Freeze
      Duration is calculated by summing the total duration of all frame
      freeze events and dividing by the number of events. This metric is
      optional. It only exists when Video Loss Concealment Method
      Type=10.

   Mean Impaired Frame Proportion (MIFP): 8 bits

 

<Huang, et al.>          Expires March 14, 2016                 [Page 7]
INTERNET DRAFT       <Video LC Metrics for RTCP XR>   September 11, 2015

      Mean Impaired Frame Proportion is the mean proportion of each
      video frame impaired by loss before applying any loss concealment
      method during the interval, expressed as a fixed point number with
      the binary point at the left edge of the field. It is calculated
      by summing the impaired proportion of each video frame and
      dividing by the number of frames during this period. The impaired
      proportion of each video frame is obtained by dividing the number
      of missing macroblocks from this video frame by the total
      macroblock number of the video frame, which is equivalent to
      multiplying the result of the division by 256, limiting the
      maximum value to 255 (to avoid overflow), and taking the integer
      part.

      If a video frame is totally lost, a value of 0xFF SHOULD be used
      for the frame when calculating the mean value.

   Mean Concealed Frame Proportion (MCFP): 8 bits

      Mean Concealed Frame Proportion is the mean proportion of each
      video frame to which loss concealment (depicted as "V" in the
      definition of "Video Loss Concealment Method Type") was applied
      during the interval, expressed as a fixed point number with the
      binary point at the left edge of the field. It is calculated by
      summing the concealed proportion of each video frame and dividing
      by the number of frames during this period. The concealed
      proportion of each video frame is obtained by dividing the number
      of concealed macroblocks from this video frame by the total
      macroblock number of the video frame, which is equivalent to
      multiplying the result of the division by 256, limiting the
      maximum value to 255 (to avoid overflow), and taking the integer
      part.

      If a lost video frame is totally concealed, a value of 0xFF and if
      there are no concealed macroblocks, a value of 0, SHOULD be used
      for the frame when calculating the mean value. For Video Loss
      Concealment Method Type=10, each frame covered in the period of
      frame freeze is considered to be totally concealed, which means a
      value of 0xFF MUST be assigned. 

   Fraction of Frames Subject to Concealment (FFSC): 8 bits

      Fraction of Frames Subject to Concealment is calculated by
      dividing the number of frames to which loss concealment (using
      Video Loss Concealment Method Type) was applied by the total
      number of frames and expressing this value as a fixed point number
      with the binary point at the left edge of the field. It is
      equivalent to multiplying the result of the division by 256,
      limiting the maximum value to 255 (to avoid overflow), and taking
 

<Huang, et al.>          Expires March 14, 2016                 [Page 8]
INTERNET DRAFT       <Video LC Metrics for RTCP XR>   September 11, 2015

      the integer part.

      A value of 0 indicates that there were no concealed frame and a
      value of 0xFF indicates that the frames in the entire measurement
      interval are all concealed. 

   Reserved: 8 bits

      These bits are reserved for future use.  They MUST be set to zero
      by senders and ignored by receivers (see Section 4.2 of
      [RFC6709]).

5 SDP Signaling

   [RFC3611] defines the use of SDP (Session Description Protocol) for
   signaling the use of RTCP XR blocks.

5.1 SDP rtcp-xr-attrib Attribute Extension

   This session augments the SDP attribute "rtcp-xr" defined in Section
   5.1 of [RFC3611] by providing an additional value of "xr-format" to 
   signal the use of the report block defined in this document.

   xr-format =/ xr-vlc-block

   xr-vlc-block = "vlc"

5.2 Offer/Answer Usage

   When SDP is used in offer-answer context, the SDP Offer/Answer usage
   defined in section 5.2 of [RFC3611] for unilateral "rtcp-xr"
   attribute parameters applies. For detailed usage of Offer/Answer for
   unilateral parameter, refer to section 5.2 of [RFC3611].

6 Security Considerations

   It is believed that this RTCP XR block introduces no new security
   considerations beyond those described in [RFC3611]. This block does
   not provide per-packet statistics, so the risk to confidentially
   documented in Section 7, paragraph 3 of [RFC3611] does not apply.

   An attacker is likely to put incorrect information in the Video Loss
   Concealment reports, which will affect the estimation of video loss
   concealment mechanisms performance and QoE of users. Implementers
   SHOULD consider the guidance in [RFC7202] for using appropriate
   security mechanisms, i.e., where security is a concern, the
   implementation SHOULD apply encryption and authentication to the
   report block. For example, this can be achieved by using the AVPF
 

<Huang, et al.>          Expires March 14, 2016                 [Page 9]
INTERNET DRAFT       <Video LC Metrics for RTCP XR>   September 11, 2015

   profile together with the Secure RTP profile as defined in [RFC3711];
   an appropriate combination of the two profiles (an "SAVPF") is
   specified in [RFC5124]. However, other mechanisms also exist
   (documented in [RFC7201]) and might be more suitable.

7 IANA Considerations

   New block types for RTCP XR are subject to IANA registration. For
   general guidelines on IANA considerations for RTCP XR, please refer
   to [RFC3611].

7.1 New RTCP XR Block Type Value

   This document assigns the block type value VLC in the IANA "RTP
   Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 
   the "Video Loss Concealment Metric Report Block".

   [Note to RFC Editor: please replace VLC with the IANA provided RTCP
   XR block type for this block.]

7.2 New RTCP XR SDP Parameter

   This document also registers a new parameter "video-loss-concealment"
   in the "RTP Control Protocol Extended Reports (RTCP XR) Session
   Description Protocol (SDP) Parameters Registry".

7.3 Contact Information for registrations

   The contact information for the registration is:

   RAI Area Directors

   rai-ads@tools.ietf.org

8 Acknowledgements

   The author would like to thank Colin Perkins, Roni Even for their
   valuable comments.

9  References

9.1  Normative References

   [RFC6776]  Clark, A. and Q. Wu, "Measurement Identity and Information
              Reporting Using a Source Description (SDES) Item and an
              RTCP Extended Report (XR) Block", RFC6776, October 2012.

   [RFC7201]  Westerlund, M. and C., Perkins, "Qptions for Securing RTP
 

<Huang, et al.>          Expires March 14, 2016                [Page 10]
INTERNET DRAFT       <Video LC Metrics for RTCP XR>   September 11, 2015

              Sessions", RFC 7201, April 2014.

   [RFC7202]  Perkins, C. and M., Westerlund, "Securing the RTP
              Framework: Why RTP Does Not Mandate a Single Media
              Security Solution", RFC 7202, April 2014.

   [RFC7294] Clark, A., Zorn, G., Bi, C. and Q., Wu, "RTCP XR Report
              Block for Concealment Metrics Reporting on Audio
              Applications", April 2014.

9.2  Informative References

   [RFC6390]  Clark, A. and B. Claise, "Guidelines for Considering New
              Performance Metric Development", BCP 170, RFC 6390,
              October 2011.

   [RFC6792]  Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
              RTP Monitoring Framework", RFC 6792, November 2012.

Appendix A. Metrics Represented Using the Template from RFC 6390

   a. Video Impaired Duration Metric

      * Metric Name: Video Impaired Duration Metric

      * Metric Description: The total time length of video impaired by
      transmission loss before applying any loss concealment methods.

      * Method of Measurement or Calculation: The metric is based on
      measurements that are typically made at the time that a video
      frame is decoded and rendered for playout.

      * Units of Measurement: This metric is expressed in units of RTP
      timestamp.

      * Measurement Point(s) with Potential Measurement Domain: It is
      measured at the receiving end of the RTP stream.

      * Measurement Timing: See paragraph 1 of Section 4.

      * Use and Applications: The metric is applicable to video
      applications of RTP and the video component of Audio/Video
      applications in which packet loss concealment mechanisms are
      applied to the receiving endpoint to mitigate the impact of
      network impairments on QoE.

   b. Video Concealed Duration Metric
 

<Huang, et al.>          Expires March 14, 2016                [Page 11]
INTERNET DRAFT       <Video LC Metrics for RTCP XR>   September 11, 2015

      * Metric Name: Video Concealed Duration Metric

      * Metric Description: The total time length of concealed damaged
      video pictures on which loss concealment method corresponding to
      Video Loss Concealment Method Type is applied.

      * Method of Measurement or Calculation: The metric is based on
      measurements that are typically made at the time that a video
      frame is decoded and rendered for playout.

      * Units of Measurement: This metric is expressed in units of RTP
      timestamp.

      * Measurement Point(s) with Potential Measurement Domain: It is
      measured at the receiving end of the RTP stream.

      * Measurement Timing: See paragraph 1 of Section 4.

      * Use and Applications: These metrics are applicable to video
      applications of RTP and the video component of Audio/Video
      applications in which packet loss concealment mechanisms are
      incorporated into the receiving endpoint to mitigate the impact of
      network impairments on QoE.

   c. Mean Video Frame Freeze Duration Metric

      * Metric Name: Mean Video Frame Freeze Duration Metric

      * Metric Description: The mean duration of the frame freeze
      events.

      * Method of Measurement or Calculation: The metric is based on
      measurements that are typically made at the time that a video
      frame is decoded and rendered for playout. The metric is
      calculated by summing the total duration of all frame freeze
      events and dividing by the number of events.

      * Units of Measurement: This metric is expressed in units of RTP
      timestamp.

      * Measurement Point(s) with Potential Measurement Domain: It is
      measured at the receiving end of the RTP stream.

      * Measurement Timing: See paragraph 1 of Section 4.

      * Use and Applications: These metrics are applicable to video
      applications of RTP and the video component of Audio/Video
      applications in which packet loss concealment mechanisms are
 

<Huang, et al.>          Expires March 14, 2016                [Page 12]
INTERNET DRAFT       <Video LC Metrics for RTCP XR>   September 11, 2015

      incorporated into the receiving endpoint to mitigate the impact of
      network impairments on QoE.

   d. Mean Impaired Video Frame Proportion Metric

      * Metric Name: Mean Impaired Video Frame Proportion Metric

      * Metric Description: Mean proportion of each video frame impaired
      by loss before applying any loss concealment method during the
      interval.

      * Method of Measurement or Calculation: The metric is based on
      measurements that are typically made at the time that a video
      frame is decoded and rendered for playout. It is calculated by
      summing the impaired proportion of each video frame and dividing
      by the number of frames during this period. The impaired
      proportion of each video frame is obtained by dividing the number
      of missing macroblocks from this video frame by the total
      macroblock number of the video frame, which is equivalent to
      multiplying the result of the division by 256, limiting the
      maximum value to 255 (to avoid overflow), and taking the integer
      part.

      * Units of Measurement: This metric is expressed as a fixed point
      number with the binary point at the left edge of the field.

      * Measurement Point(s) with Potential Measurement Domain: It is
      measured at the receiving end of the RTP stream.

      * Measurement Timing: See paragraph 1 of Section 4.

      * Use and Applications: These metrics are applicable to video
      applications of RTP and the video component of Audio/Video
      applications in which packet loss concealment mechanisms are
      incorporated into the receiving endpoint to mitigate the impact of
      network impairments on QoE.

   e. Mean Concealed Video Frame Proportion Metric

      * Metric Name: Mean Concealed Video Frame Proportion Metric

      * Metric Description: Mean proportion of each video frame to which
      loss concealment (using Video Loss Concealment Method Type) was
      applied during the interval.

      * Method of Measurement or Calculation: The metric is based on
      measurements that are typically made at the time that a video
      frame is decoded and rendered for playout. It is calculated by
 

<Huang, et al.>          Expires March 14, 2016                [Page 13]
INTERNET DRAFT       <Video LC Metrics for RTCP XR>   September 11, 2015

      summing the concealed proportion of each video frame and dividing
      by the number of frames during this period. The concealed
      proportion of each video frame is obtained by dividing the number
      of concealed macroblocks from this video frame by the total
      macroblock number of the video frame, which is equivalent to
      multiplying the result of the division by 256, limiting the
      maximum value to 255 (to avoid overflow), and taking the integer
      part.

      * Units of Measurement: This metric is expressed as a fixed point
      number with the binary point at the left edge of the field.

      * Measurement Point(s) with Potential Measurement Domain: It is
      measured at the receiving end of the RTP stream.

      * Measurement Timing: See paragraph 1 of Section 4.

      * Use and Applications: These metrics are applicable to video
      applications of RTP and the video component of Audio/Video
      applications in which packet loss concealment mechanisms are
      incorporated into the receiving endpoint to mitigate the impact of
      network impairments on QoE.

   f. Fraction of Video Frames Subject to Concealment Metric

      * Metric Name: Fraction of Video Frames Subject to Concealment
      Metric

      * Metric Description: Proportion of concealed video frames to
      which loss concealment (using Video Loss Concealment Method Type)
      was applied comparing to the total number of frames during the
      interval.

      * Method of Measurement or Calculation: The metric is based on
      measurements that are typically made at the time that a video
      frame is decoded and rendered for playout. This metric is
      calculated by dividing the number of frames to which loss
      concealment (using Video Loss Concealment Method Type) was applied
      by the total number of frames. It is equivalent to multiplying the
      result of the division by 256, limiting the maximum value to 255
      (to avoid overflow), and taking the integer part.

      * Units of Measurement:  This metric is expressed as a fixed point
      number with the binary point at the left edge of the field.

      * Measurement Point(s) with Potential Measurement Domain: It is
      measured at the receiving end of the RTP stream.

 

<Huang, et al.>          Expires March 14, 2016                [Page 14]
INTERNET DRAFT       <Video LC Metrics for RTCP XR>   September 11, 2015

      * Measurement Timing: See paragraph 1 of Section 4.

      * Use and Applications: These metrics are applicable to video
      applications of RTP and the video component of Audio/Video
      applications in which packet loss concealment mechanisms are
      incorporated into the receiving endpoint to mitigate the impact of
      network impairments on QoE.

Authors' Addresses

   Rachel Huang
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing 210012
   China

   EMail: rachel.huang@huawei.com

   Alan Clark
   Telchemy Incorporated
   2905 Premiere Parkway, Suite 280
   Duluth, GA  30097
   USA

   Email: alan.d.clark@telchemy.com

<Huang, et al.>          Expires March 14, 2016                [Page 15]