织梦CMS - 轻松建站从此开始!

罗索

Splicing for MPEG2-TS Problem Statement in RTP Sessions

落鹤生 发布于 2010-04-22 22:24 点击:次 
由华为刚刚于4月20号递交的一份草案,能不能通过还不一定,但是这不是我关注的重点,重点是在于国内目前的热点话题:三网合一。这必将是一个非常重要的点,至少在未来的一段时间内。
TAG:

AVT Working Group J. Xia
Internet-Draft H. Xia Intended
status: Informational J. Zhang April 20, 2010
Expires: October 22, 2010
 

Splicing for MPEG2-TS Problem Statement in RTP Sessions
draft-xia-avt-splicing-for-mpeg2ts-ps-01

Abstract

The base MPEG2-TS splicing related protocols, i.e., Digital Program Insertion Splicing API [SCTE30] and Digital Program Insertion Cueing Message for Cable [SCTE35], only take into account how to insert the content (e.g., spot advertisements of various lengths, program substitution, public service announcements, etc) into any MPEG2-TS output multiplex on the splicer , as well as how to carry notification of upcoming splicing and other timing information in the transport stream, but not give enough mechanisms to direct the underlying transport protocol such as RTP how to compatibly work with the MPEG2-TS splicing. This memo highlights the issues of what's the impact on RTP and RTCP when performing splicing between the primary channel and the insertion channel.

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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on October 22, 2010. 


Internet-Draft            seamless splicing ps                April 2010


   Provisions Relating to IETF Documents
   (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
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Overlap between Insertion Channel and Primary Channel  . .  6
     3.2.  Gap between Insertion Channel and Primary Channel  . . . .  7
   4.  Potential Approach Considerations  . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10




























Xia, et al.             Expires October 22, 2010                [Page 2]

Internet-Draft            seamless splicing ps                April 2010


1.  Introduction

   MPEG2 Transport Stream (MPEG2-TS) [MPEG2TS] is an encapsulation
   method and transport that multiplexes digital video and audio
   content, together with ancillary metadata, and produces a
   synchronized multiplexed stream that is tailored for transport over
   packet or cell-oriented networks.  MPEG2-TS are composed of 188 byte
   TS Packets, whose payloads may contain program information as well as
   Packetized Elementary Streams (PES), typically video and audio
   streams.  The RTP payload format for carrying TS packets in an RTP
   stream is specified in [RFC2250].

   With the expansive application of the MPEG2-TS, operators will need
   solutions that can efficiently manage and process an increasing
   number of ads.  One specific solution that can process and splice
   hundreds of ads in a single device is Digital Program Insertion (DPI)
   which involve the splicing of a single primary channel stream and ads
   channel streams in most cases into a output channel.  Splicer is the
   key network entity, which seamlessly insert valuable ads into primary
   channel.  With Digital Program Insertion, splicer can replace a
   national advertising slot with a local ad.  The details to describing
   splicing configuration defined in [SCTE30] are shown in Figure 1.


        Primary Channel  +-----------+
             ----------->|           | Output Channel
                         |  Splicer  |---------->
              ---------->|           |
             |           +-----------+
             |                    ^
             | Insertion Channel  '
             |                    '
       +----------+               '
       |          |               '
       |  Server  | <''''''''''''''
       |          |      Signaling Connection
       +----------+

    ---------->  Data

    ''''''''''>  Signaling

      Figure 1:  Single Splicing Configuration


   [SCTE30] creates a standardized method for communication between
   server and splicer for the insertion of content into any MPEG2-TS
   output multiplex on the splicer.  Based on the cue message [SCTE35],



Xia, et al.             Expires October 22, 2010                [Page 3]

Internet-Draft            seamless splicing ps                April 2010


   server and splicer know when to start a splicing as well as the
   duration of splicing, i.e., avail time.

   However SCET only takes into account the splicing process on
   application layer for MPEG2-TS regardless of the underlying transport
   layer, such as RTP.  From this viewpoint, this processing does not
   cause any problem to CATV operators who directly transfer MPEG2-TS
   over cable.  CATV operators continuously output the ads MPEG2-TS
   instead of primary program on splicer and return to the primary
   program after the avail time.  The whole procedure only operates on
   the MPEG2-TS layer without any transport layer operation.

   However IPTV operators who provide IP-based video services have to
   face the issues raised by MPEG2-TS splicing.  In IPTV deployments,
   splicer not only performs MPEG2-TS splicing but also needs to
   coordinate underlying RTP layer to be compatible with MPEG2-TS
   splicing.  By deeply detecting the timing information conveied in
   MPEG2-TS payload specified in [SCTE35], splicer can clearly know how
   to perform MPEG2-TS splicing.  During the certain avail time, the
   number of ads RTP packets, which are inserted into primary program on
   splicer , is variable due to the different entropy coding.
   Therefore, in most case, the number of inserted ads RTP packets are
   hardly equal to the number of overridden primary program RTP packets.
   If the splicing between insertion channel and primary channel can not
   be appropriately handled by splicer at the beginning and end of avail
   time, the RTP sequence number gap or overlap between insertion
   channel RTP packets and primary channel RTP packets maybe result in
   the RTP receiver to request unnecessary retransmission for inexistent
   packet missing or discard the useful packets due to the reduplicate
   sequence number respectively.  The use cases where the problems exist
   are briefly described in Section 3.


2.  Terminology

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

   Throughout this document, the terms used have specific meanings.
   Because some of the terms that are defined in SCTE30 and SCTE35 have
   very specific technical meanings, the reader is referred to the
   original source for their definition.  For terms used in this
   document, brief definitions are given below.







Xia, et al.             Expires October 22, 2010                [Page 4]

Internet-Draft            seamless splicing ps                April 2010


   Digital Program Insertion (DPI)

      The digital splicing of MPEG programs into other MPEG programs.
      Digital Program Insertion includes content such as spot ads of
      various lengths, program substitution, public service
      announcements or program material created by splicing portions of
      the program from an ad server.

   Avail

      Time space provided to operators by programming services during a
      program for use by the operator; the time is usually sold to local
      advertisers or used for channel self promotion.

   Channel

      Channel is a synonym for a "Service" in DVB terminology, or a
      "Program" in MPEG terminology.

   Primary Channel

      The Primary Multiplex Channel carrying MPEG2-TS.  It is spliced in
      whole or in part by Insertion Channel.

   Insertion Channel

      The Insertion Multiplex Channel(s) that replace the Primary
      Channel in whole or in part for the duration of a splicing.

   Splicer

      The device that splices the Insertion Channel(s) into the Primary
      Channel.  It may receive cue messages [SCTE35].  This device also
      communicates with the Server about when to start and end the
      splicing [SCTE30].

   Output Channel

      The Channel that is produced at the output of the splicer

   Server

      The device that originates the Insertion Channel(s) to be spliced
      into the Primary Channel.  This device communicates with the
      splicer about when and what to splice.






Xia, et al.             Expires October 22, 2010                [Page 5]

Internet-Draft            seamless splicing ps                April 2010


3.  Use Cases

   In this section, two use cases are listed to illustrate the issues
   resulting from this imperfect splicing on RTP layer.

3.1.  Overlap between Insertion Channel and Primary Channel

   Figure 2 gives the overlap issue between insertion channel RTP
   packets and primary channel RTP packets at the end of avail time.


                       '                           '
      Primary Channel  '<-------Avail Time-------->'
                       '                           '
     +-----+   +-----+ '     +-----+  +-----+      ' +-----+   +-----+
     | SN1 |...| SN15| '     | SN16|  | SN17|      ' | SN18|...| SN25|
     +-----+   +-----+ '     +-----+  +-----+      ' +-----+   +-----+
        |         |    '                           '    |         |
        |         |    '                           '    |         |
        |         |    '     Insertion Channel     '    |         |
        |         |    '                           '    |         |
        |         |    ' +-----+  +-----+  +-----+ '    |         |
        |         |    ' | SN1 |  | SN2 |  | SN3 | '    |         |
        |         |    ' +-----+  +-----+  +-----+ '    |         |
        |         |    '    |        |        |    '    |         |
        |         |    '    |        |        |    '    |         |
        |         |    '    |        |        |    '    |         |
        v         v    '    v        v        v    '    v         v
     +-----+   +-----+ ' +-----+  +-----+  +-----+ ' +-----+   +-----+
     | SN1 |...| SN15| ' | SN16|  | SN17|  | SN18| ' | SN18|...| SN25|
     +-----+   +-----+ ' +-----+  +-----+  +-----+ ' +-----+   +-----+
                       '                           '
      Output Channel   '                           '


             Figure 2: Overlap at the end of insertion


   1.  Before the splicing, the stream of output channel on splicer is
       from primary channel.

   2.  At the beginning of avail time, the splicer switches this
       insertion channel stream to the output channel.  In order to
       achieve seamless switch-over, splicer needs to coordinate the
       insertion channel RTP packets with pervious primary channel RTP
       packets prior to delivering them to output channel.  For example,
       in Figure 2, the sequence number of last primary channel RTP
       packet is SN15.  In order to avoid confusion on RTP receiver, the



Xia, et al.             Expires October 22, 2010                [Page 6]

Internet-Draft            seamless splicing ps                April 2010


       new sequence number of next insertion channel RTP packet should
       be changed to SN16 from SN1 on splicer , and the rest insertion
       channel RTP packets also comply with the increments.

   3.  At the end of avail time, the splicer returns to the primary
       channel for direction to the output channel.  If the number of
       insertion channel RTP packets delivered through output channel
       are more than the number of overridden primary channel RTP
       packets during certain avail time, splicer also needs to
       coordinate the subsequent primary channel RTP packets with
       pervious insertion channel RTP packets prior to delivering them
       to output channel.  Otherwise, the sequence number overlap of
       insertion channel RTP packets and primary channel RTP packets may
       induce RTP receiver to discard the subsequently valid primary
       channel RTP packets due to the duplicate sequence number(s).  For
       example, in Figure 2, two primary channel RTP packets are
       overridden by three insertion channel RTP packets during certain
       avail time, the next primary channel RTP packet, whose sequence
       number is SN18, may be wrongly discarded by RTP receiver as a
       redundant RTP packet.


3.2.  Gap between Insertion Channel and Primary Channel

   Figure 3 gives the gap issue between insertion channel RTP packets
   and primary channel RTP packets at the end of avail time.

























Xia, et al.             Expires October 22, 2010                [Page 7]

Internet-Draft            seamless splicing ps                April 2010


                      '                           '
     Primary Channel  '<-------Avail Time-------->'
                      '                           '
    +-----+   +-----+ ' +-----+  +-----+  +-----+ ' +-----+   +-----+
    | SN1 |...| SN15| ' | SN16|  | SN17|  | SN18| ' | SN19|...| SN25|
    +-----+   +-----+ ' +-----+  +-----+  +-----+ ' +-----+   +-----+
       |         |    '                           '    |         |
       |         |    '                           '    |         |
       |         |    '     Insertion Channel     '    |         |
       |         |    '                           '    |         |
       |         |    '     +-----+  +-----+      '    |         |
       |         |    '     | SN1 |  | SN2 |      '    |         |
       |         |    '     +-----+  +-----+      '    |         |
       |         |    '        |        |         '    |         |
       |         |    '        |        |         '    |         |
       |         |    '        |        |         '    |         |
       v         v    '        v        v         '    v         v
    +-----+   +-----+ '     +-----+  +-----+      ' +-----+   +-----+
    | SN1 |...| SN15| '     | SN16|  | SN17|      ' | SN19|...| SN25|
    +-----+   +-----+ '     +-----+  +-----+      ' +-----+   +-----+
                      '                           '
     Output Channel   '                           '


             Figure 3: Gap at the end of insertion


   1.  First two steps are same as overlap issue specified in
       Section 3.1

   2.  At the end of avail time, the splicer returns to the primary
       channel for direction to the output channel.  If the number of
       insertion channel RTP packets delivered through output channel
       are less than the number of overridden primary channel RTP
       packets during certain avail time, splicer also needs to
       coordinate the subsequent primary channel RTP packets with
       pervious insertion channel RTP packets prior to delivering them
       to output channel.  Otherwise, the sequence number gap of
       insertion channel RTP packets and primary channel RTP packets may
       induce RTP receiver to request unnecessary retransmission for
       inexistent packet loss due to the missing sequence numbers.  For
       example, in Figure 3, three primary channel RTP packets are
       overridden by two insertion channel RTP packets during certain
       avail time, the next primary channel RTP packet, whose sequence
       number is SN19, may misguide RTP receiver to request
       retransmission of an inexistent RTP packet whose sequence number
       is SN18.




Xia, et al.             Expires October 22, 2010                [Page 8]

Internet-Draft            seamless splicing ps                April 2010


4.  Potential Approach Considerations

   A powerful translator defined in [RFC3550] can be designed as splicer
   and support splicing related operations.  When receiving primary
   channel RTP packets and insertion channel RTP packets, the translator
   firstly decodes these RTP packets and performs MPEG2-TS splicing
   specified in [SCTE30], then re-encode the MPEG2-TS according to the
   payload format defined in [RFC2250] with their SSRC identifier
   intact, but assign new sequence numbers to the output channel RTP
   packets.

   However, usage of translator is rather usual in a video conference
   scenario than in a splicing scenario.  Translator has to continuously
   decode and encode primary channel RTP packets even if next splicing
   event is far from coming, or even no splicing event occurs again.
   For example, a translator, which plan to insert the next ad into a
   football game, will wait at least 45 minutes before performing
   splicing at half-time.  In such case, the additional overhead is
   introduced on translator when it performs unnecessary decoding and
   encoding of the football game.

   Herein, in addition to modify RTP packets, translator must not simply
   forward RTCP packets.  Translator must make corresponding
   transformations in the SR and RR information so that it still
   reflects the characteristics of the data and the reception quality.
   It is more complex compared to just forwarding RTCP packets
   unmodified.

   Furthermore, a splicer may serve more than one primary channels
   simultaneously, the heavy-laden splicer may has unpredictable
   overhead when performing splicing.

   To avoid the aforementioned issues, a more efficient splicing
   mechanism on RTP/RTCP layer can be justified that would be part of
   the RTP/RTCP base protocol.


5.  Security Considerations

   The security considerations of translators which are described in
   section 7 of [RFC3550] and in section 5 of [RFC5117] also apply to
   this document.


6.  IANA Considerations

   This document has no IANA actions.




Xia, et al.             Expires October 22, 2010                [Page 9]

Internet-Draft            seamless splicing ps                April 2010


7.  Acknowledgments

   The author would like to thank Colin Perkins for his reviews and
   comments on the initial version of this document.


8.  Normative References

   [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.

   [RFC2250]  Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar,
              "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250,
              January 1998.

   [RFC5117]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
              January 2008.

   [SCTE30]   Society of Cable Telecommunications Engineers (SCTE),
              "Digital Program Insertion Splicing API", 2001.

   [SCTE35]   Society of Cable Telecommunications Engineers (SCTE),
              "Digital Program Insertion Cueing Message for Cable",
              2004.

   [MPEG2TS]  "Generic Coding of Moving Pictures and Associated Audio
              Information: Systems", 2006.


Authors' Addresses

   Jinwei Xia
   Huawei
   Hui Hong Mansion
   Nanjing, Baixia District  210001
   China

   Phone: +86-025-84565890
   Email: xiajinwei@huawei.com








Xia, et al.             Expires October 22, 2010               [Page 10]

Internet-Draft            seamless splicing ps                April 2010


   Hui Xia
   Huawei
   Site B,Floor 12F,Huihong Mansion, No.91 Baixia Rd.
   Nanjing, Jiangsu  21001
   China

   Phone: +86-25-84565868
   Email: rakexia@huawei.com


   Jinhui Zhang
   Huawei
   Site B,Floor 12F,Huihong Mansion, No.91 Baixia Rd.
   Nanjing, Jiangsu  21001
   China

   Phone: +86-25-84565866
   Email: zhang.jinhui@huawei.com

































Xia, et al.             Expires October 22, 2010               [Page 11]


(Hui Xia)
本站文章除注明转载外,均为本站原创或编译欢迎任何形式的转载,但请务必注明出处,尊重他人劳动,同学习共成长。转载请注明:文章转载自:罗索实验室 [http://www.rosoo.net/a/201004/9231.html]
本文出处:ietf.org 作者:Hui Xia
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 验证码:点击我更换图片
栏目列表
将本文分享到微信
织梦二维码生成器
推荐内容