One document matched: draft-huang-xrblock-rtcp-xr-video-lc-02.txt
Differences from draft-huang-xrblock-rtcp-xr-video-lc-01.txt
XRBLOCK R. Huang
INTERNET-DRAFT Huawei
Intended Status: Standards Track A. Clark
Expires: April 23, 2015 Telchemy
October 20, 2014
RTCP XR Report Block for Loss Concealment Metrics Reporting on
Video Applications
draft-huang-xrblock-rtcp-xr-video-lc-02
Abstract
This draft defines a new video loss concealment block type to augment
those defined in [RFC3611] and [i.d-ietf-xrblock-rtcp-xr-loss-
concealment] 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) 2014 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 April 23, 2015 [Page 1]
INTERNET DRAFT <Video LC Metrics for RTCP XR> October 20, 2014
(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 . . . . . . . . . . . . . 4
5 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . . 7
5.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . . 7
6 Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7.1 New RTCP XR Block Type Value . . . . . . . . . . . . . . . . 8
7.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 8
7.3 Contact Information for registrations . . . . . . . . . . . 8
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 April 23, 2015 [Page 2]
INTERNET DRAFT <Video LC Metrics for RTCP XR> October 20, 2014
1 Introduction
Multimedia applications often suffer from packet losses in IP
networks. In order to get 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 [i.d-ietf-xrblock-rtcp-xr-
loss-concealment] 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 April 23, 2015 [Page 3]
INTERNET DRAFT <Video LC Metrics for RTCP XR> October 20, 2014
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
In this draft, video loss concealment mechanisms are classified into
4 types as follow:
a) Frame freeze
The impaired video frame is not displayed, instead, the previously
displayed frame is hence 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.
4. Video Loss Concealment Report Block
This block reports the video loss concealment metrics to complement
<Huang, et al.> Expires April 23, 2015 [Page 4]
INTERNET DRAFT <Video LC Metrics for RTCP XR> October 20, 2014
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 | VLCM | block length=6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Free Video Image Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Impaired Video Image Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIFP | MCFP | 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 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
accumulation period characteristic of cumulative measurements.
I=01: Sampled Value - this value MUST NOT be used for this
<Huang, et al.> Expires April 23, 2015 [Page 5]
INTERNET DRAFT <Video LC Metrics for RTCP XR> October 20, 2014
block type.
I=00: Reserved.
Video Loss Concealment Method Type (VLCM): 6 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:
bit 014 - Frame freeze
bit 015 - Inter-frame extrapolation
bit 016 - Interpolation
bit 017 - Error Resilient
bit 018 - Other Loss Concealment Method
bit 019 - Reserved
Setting the bit means corresponding type of mechanisms are used.
Multiple types of method are allowed to use together. For example,
Applications could use RTP retransmission to recovery some lost
packets and use noise insertion to conceal some losses that could
not be fixed.
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].
Loss Free Video Image Duration: 32 bits
The total time length, expressed in units of millisecond, of
received video with no transmission loss.
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.
Loss Impaired Video Image Duration: 32 bits
The total time length, expressed in units of millisecond, of still
impaired video pictures, which have transmission loss and to which
loss concealment may have been applied.
<Huang, et al.> Expires April 23, 2015 [Page 6]
INTERNET DRAFT <Video LC Metrics for RTCP XR> October 20, 2014
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
Mean Impaired Frame Proportion is the mean proportion of each
video frame impaired by loss during the Loss Impaired Video Image
Duration period. If a video frame is totally lost, the MIFP of
this frame is set to 100.
One values are reserved: A value of 0xFFFF indicates that the
measurement is unavailable.
Mean Concealed Frame Proportion(MCFP): 8 bits
Mean Concealed Frame Proportion is the mean proportion of each
video frame with concealed loss impairments during the Loss
Impaired Video Image Duration period. If a lost video frame is
totally concealed, the MCFP is set to 100; If there are no
concealed macroblocks in a lost or partial lost video frame, the
MCFP of this frame is set 0.
One values are reserved: A value of 0xFFFF indicates that the
measurement is unavailable.
Reserved: 16 bits
These bits are reserved. They MUST be set to zero by senders and
ignored by receivers (See [RFC6709] section 4.2).
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
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
<Huang, et al.> Expires April 23, 2015 [Page 7]
INTERNET DRAFT <Video LC Metrics for RTCP XR> October 20, 2014
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.]
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
<Huang, et al.> Expires April 23, 2015 [Page 8]
INTERNET DRAFT <Video LC Metrics for RTCP XR> October 20, 2014
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, Jonathan
Lennox to provide 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.
[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.
<Huang, et al.> Expires April 23, 2015 [Page 9]
INTERNET DRAFT <Video LC Metrics for RTCP XR> October 20, 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.
[i.d-ietf-xrblock-rtcp-xr-loss-concealment] 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
Duluth, GA 30097
USA
Email: alan.d.clark@telchemy.com
<Huang, et al.> Expires April 23, 2015 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 03:29:07 |