One document matched: draft-yang-avt-rtp-synced-playback-00.txt


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]


PAFTECH AB 2003-20262026-04-24 01:14:49