Audio/Video Transport WG P. Yang Internet Draft Y.-K. Wang Intended status: Standards track Huawei Technologies Expires: January 2010 July 6, 2009 Synchronized Playback in Rapid Acquisition of Multicast Sessions draft-yang-avt-rtp-synced-playback-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 6, 2010. Yang & Wang Expires January 6, 2010 [Page 1] Internet-Draft Synchronized playback July 2009 Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract When watching the same IPTV channel, different TV sets may not render the same picture and the associated audio at the same moment. This variation of end-to-end delay between users is referred to as inter-user playback delay. Unicast based rapid acquisition of multicast RTP sessions (RAMS) as specified in [I-D.ietf-avt-rapid- acquisition-for-rtp] is an important technique in achieving fast channel switching in IPTV applications. In addition, RAMS also significantly relaxes the requirement of relatively short random access point period in encoding of video streams in multicast applications, thus allowing significantly improved compression efficiency. However, on the other hand, the use of RAMS increases inter-user playback delay. This document specifies a mechanism to help reduce inter-user playback delay in RAMS. Table of Contents 1. Introduction..................................................3 2. Conventions...................................................4 3. Definitions...................................................5 4. Inter-User Playback Delay Reduction...........................5 5. Message Extensions............................................5 5.1. Extension to RAMS-R......................................6 5.2. Extension to RAMS-I......................................6 6. Security Considerations.......................................6 7. IANA Considerations...........................................6 8. Acknowledgements..............................................6 9. References....................................................6 10. Authors' Addresses...........................................7 Yang & Wang Expires January 6, 2010 [Page 2] Internet-Draft Synchronized playback July 2009 1. Introduction The Internet-Draft "Unicast-Based Rapid Acquisition of Multicast RTP Sessions" in [I-D.ietf-avt-rapid-acquisition-for-rtp] presents a method based on unicast burst stream for rapid acquisition of multicast RTP sessions (RAMS), thus to reduce the waiting time for the so-called Reference Information (RI). This method is effective in reducing channel switching and tune-in delay in multicast applications, such as IPTV. The RI typically starts at an access unit that is a random access point. In RAMS, RTP receivers start playback from the random access point from which the RI starts when they switch from one multicast session to another. As the unicast burst stream starts from the RI and is transmitted as fast as possible and faster than the media rate, on average the receiver can start processing the unicast burst stream almost immediately, and does not need to wait for the next random access point if it directly joined the multicast group. Another important benefit brought by RAMS is that significantly improved coding efficiency for video streams is possible. In conventional multicast applications, video streams must be encoded with frequent random access points, e.g. 0.5 to 1 second, to allow new receivers to tune-in or existing users to switching from another multicast session. Random access points typically contain intra-coded pictures, for which the compression efficiency is significantly, e.g., several to ten times, lower than inter-coded pictures. Therefore, the less the random access points, the higher the coding efficiency. When RAMS is in use, random access period length is less critical for the tune-in or channel switching delay. This means that the video random access point frequency can be significantly reduced, leading to significantly improved compression efficiency. In multicast applications, receivers receiving the same multicast session can not playback the same content in an absolutely synchronized manner, due to the variation in various delays including end-to-end transmission delay, receiver buffering delay, decoding buffering delay, and output buffering delay. Moreover, events like session transfer or rebroadcast can further increase inter-user playback delay. Thus, different users may watch different pictures from different TV sets when watching the same IPTV content. In this document, this playback delay variation between different users is referred to as inter-user playback delay. Yang & Wang Expires January 6, 2010 [Page 3] Internet-Draft Synchronized playback July 2009 In some application scenarios, e.g., remote education or a discussion room for an ongoing TV program in a social network, different users may be discussing the same content received through multicast. In this case, an obvious playback synchronization loss due to excessive inter-user playback delay can generate bad user experience. A disadvantage of RAMS is that the use of the technique increases inter-user playback delay. Regardless of when the receiver starts the RAMS request (i.e. joins the program), the playback will start from the previous random access point. Thus, the later the receiver joins the program in between two random access points, the longer the display delay will the user have compared to other users. The longest inter-user playback delay due to the use of RAMS is close to the interval between the two random access points, when one user joins the program right after the first random access point while another user joins the program right before second random access point, as depicted in Figure 1 below. In Figure 1, the two I frames are two consecutive random access points. IBBPBBPBBPBBPBBPBBPBBPBBPBBPBBPBBPBBPBBPBBPBBPBBPBBP...BBPBBPI... ^ ^ | | |<--The longest inter-user playback delay due to RAMS use-->| Figure 1 Inter-user playback delay due to the use of RAMS As can be seen from the above analysis, the issue of inter-user playback delay also constrains the use of long random access period length for improved compression efficiency, which has been another important benefit of RAMS. In this document, we describe a mechanism to reduce inter-user playback delay and to allow the use of long random access period length for improved compression efficiency when RAMS is in use. 2. Conventions 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 RFC 2119 [RFC2119]. Yang & Wang Expires January 6, 2010 [Page 4] Internet-Draft Synchronized playback July 2009 3. Definitions This document uses the following acronyms and definitions: Inter-User Playback Delay: The playback delay between different users for the same content on the same multicast session. 4. Inter-User Playback Delay Reduction The mechanism involves the following changes to the RAMS method: 1) When the RTP Receiver (RR) sends a rapid acquisition request for the new multicast RTP session, the request MAY contain additional information indicating whether RR supports inter-user playback delay reduction. 2) When the Retransmission Sever (RS) receives the RAMS-R message and decides to accept it, RS MAY include the following additional information in the RAMS-I message to RR: a) N, the playback delay reduction target in number of frame durations; and b) V, recommended interval, in frames, between two continuous events for skipping of one frame. When the RAMS-R message indicates that RR supports inter-user playback delay reduction, RS SHOULD include the above information in the RAMS-I message. 3) When RR receives an RAMS-I message containing the above information, it SHOULD speed up media rendering during playback taking into account the information as follows. During the speedup playback, after each V frames, one frame is skipped as if it was not present, and the presentation time of each remaining frame is shifted earlier by one frame duration, until totally N frames have been skipped. Receivers will playback the media content with its original speed after totally N frames have been skipped. Note that decoding remains the same as if speedup playback was not in use. 5. Message Extensions This section defines the extensions to RAMS-R and RAMS-I messages for inter-user playback delay reduction. Yang & Wang Expires January 6, 2010 [Page 5] Internet-Draft Synchronized playback July 2009 5.1. Extension to RAMS-R TBD. 5.2. Extension to RAMS-I TBD. 6. Security Considerations TBD. 7. IANA Considerations TBD. 8. Acknowledgements TBD. This document was prepared using 2-Word-v2.0.template.dot. 9. References [I-D.ietf-avt-rapid-acquisition-for-rtp] Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- Based Rapid Acquisition of Multicast RTP Sessions", draft-ietf-avt-rapid-acquisition-for-rtp-01 (work in progress), June 2009. [I-D.ietf-avt-rtcp-guidelines] Ott, J. and C. Perkins, "Guidelines for Extending the RTP Control Protocol (RTCP)", draft-ietf-avt-rtcp-guidelines- 01 (work in progress), March 2009. [RFC2119] 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. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. Yang & Wang Expires January 6, 2010 [Page 6] Internet-Draft Synchronized playback July 2009 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. 10. Authors' Addresses Peilin Yang Huawei Technologies Co., Ltd. No.91,Baixia Road, Nanjing 210001 P. R. China Phone: +86-25-84565881 EMail: yangpeilin@huawei.com Ye-Kui Wang Huawei Technologies Co., Ltd. 400 Somerset Corp Blvd, Suite 602 Bridgewater, NJ 08807 USA Phone: +1-908-541-3518 EMail: yekuiwang@huawei.com Yang & Wang Expires January 6, 2010 [Page 7]