RTCP XR Report Block for Loss Concealment Metrics Reporting on Video Applications
draft-ietf-xrblock-rtcp-xr-video-lc-00
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-02-25 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Last Call review
(of
-05)
by Elwyn Davies
Ready w/nits
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 7867 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-xrblock-rtcp-xr-video-lc-00
XRBLOCK R. Huang INTERNET-DRAFT Huawei Intended Status: Standards Track A. Clark Expires: August 29, 2015 Telchemy February 25, 2015 RTCP XR Report Block for Loss Concealment Metrics Reporting on Video Applications draft-ietf-xrblock-rtcp-xr-video-lc-00 Abstract This draft defines a new video loss concealment block type to augment those defined in [RFC3611] and [RFC7294] for use in a range of RTP video applications. 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 August 29, 2015 [Page 1] INTERNET DRAFT <Video LC Metrics for RTCP XR> February 25, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . . 7 5.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . . 8 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7.1 New RTCP XR Block Type Value . . . . . . . . . . . . . . . . 8 7.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 9 7.3 Contact Information for registrations . . . . . . . . . . . 9 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1 Normative References . . . . . . . . . . . . . . . . . . . 9 9.2 Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Metrics Represented Using the Template from RFC 6390 . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 <Huang, et al.> Expires August 29, 2015 [Page 2] INTERNET DRAFT <Video LC Metrics for RTCP XR> February 25, 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 MUST be 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 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. 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 system to <Huang, et al.> Expires August 29, 2015 [Page 3] INTERNET DRAFT <Video LC Metrics for RTCP XR> February 25, 2015 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 may simply re-use the pixels that were in the missing area while more complex decoders may try to use several frames to do a more complex extrapolation. c) Interpolation A decoder may user the undamaged pixels in the video frame to estimate what the missing block of pixels should have. d) Error Resilient Encoding The sender may encode the message in a redundant way so that receiver can correct errors using the redundant information. The redundant data useful for error resiliency performed at the decoder can be embedded into the compressed image/video bitstream. For example, the encoder may select an important area of an original video frame, extract some important characteristics of this area, e.g., motion vector of each macroblock, and imperceptibly embed them into other parts of the video frame. FEC is also another error resilient method. In this document, we differentiate between frame freeze and the other 3 concealment mechanisms described. <Huang, et al.> Expires August 29, 2015 [Page 4] INTERNET DRAFT <Video LC Metrics for RTCP XR> February 25, 2015 4. Video Loss Concealment Report Block This block reports the video loss concealment metrics to complement the audio metrics defined in [i.d-ietf-xrblock-rtcp-xr-loss- concealment]. This block may be stacked with other RTCP packets to form compound RTCP packets and share the average reporting interval calculated by the RTCP method described in [RFC3550]. It should be noted that 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 metrics in this block MUST be measured at a consistent point. 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=6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Impaired Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Concealed Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MIFP | MCFP | FFSC | MFFD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 metric is an interval, cumulative, or sampled metric [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 <Huang, et al.> Expires August 29, 2015 [Page 5] INTERNET DRAFT <Video LC Metrics for RTCP XR> February 25, 2015 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. Each bit indicates one method type, as follow: V=10 - Frame freeze V=11 - Other Loss Concealment Method V=01&00 - Reserved block length: 16 bits This field is in accordance with the definition in [RFC3611]. In this report block, it MUST be set to 6. 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, 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, of concealed damaged video pictures on which loss concealment method corresponding to V 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 Impaired Frame Proportion (MIFP): 8 bits <Huang, et al.> Expires August 29, 2015 [Page 6] INTERNET DRAFT <Video LC Metrics for RTCP XR> February 25, 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 equivalent to taking the integer part after multiplying the loss fraction by 256. If a video frame is totally lost, a value of 0xFF shall 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 (using V) was applied during the interval, expressed as a fixed point number with the binary point at the left edge of the field. It is equivalent to taking the integer part after multiplying the loss fraction by 256. If a lost video frame is totally concealed, a value of 0xFF and if there are no concealed macroblocks, a value of 0, shall be used for the frame when calculating the mean value. 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 V) 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 taking the integer part after multiplying the loss fraction by 256. 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. Mean Frame Freeze Duration (MFFD): 8 bits Mean Frame Freeze Duration is the mean duration of the frame freeze events. The value of MFFD shall be calculated by summing the total duration of all frame freeze events and dividing by the number of events. A value of 0xFF shall be used to indicate a value in excess of 12700 milliseconds. A value of 0 MUST be set when V=11. 5 SDP Signaling [RFC3611] defines the use of SDP (Session Description Protocol) for signaling the use of RTCP XR blocks. However XR blocks MAY be used without prior signaling (see section 5 of [RFC3611]). 5.1 SDP rtcp-xr-attrib Attribute Extension <Huang, et al.> Expires August 29, 2015 [Page 7] INTERNET DRAFT <Video LC Metrics for RTCP XR> February 25, 2015 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 = "video-loss-concealment" 5.2 Offer/Answer Usage When SDP is used in offer-answer context, the SDP Offer/Answer usage defined in [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 may put incorrect information in the Video Loss Concealment reports, which will be 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 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, 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 Metrics Report Block". [Note to RFC Editor: please replace VLC with the IANA provided RTCP XR block type for this block.] <Huang, et al.> Expires August 29, 2015 [Page 8] INTERNET DRAFT <Video LC Metrics for RTCP XR> February 25, 2015 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 following contact information is provided for all registrations in this document: Rachel Huang (rachel.huang@huawei.com) 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China 8 Acknowledgements The author would like to thank Colin Perkins, Roni Even for their valuable comments. 9 References 9.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008. <Huang, et al.> Expires August 29, 2015 [Page 9] INTERNET DRAFT <Video LC Metrics for RTCP XR> February 25, 2015 [RFC5105] Lendl, O., "ENUM Validation Token Format Definition", RFC 5105, December 2007. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. [RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP 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 TBD. 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 <Huang, et al.> Expires August 29, 2015 [Page 10] INTERNET DRAFT <Video LC Metrics for RTCP XR> February 25, 2015 Duluth, GA 30097 USA Email: alan.d.clark@telchemy.com <Huang, et al.> Expires August 29, 2015 [Page 11]