AVT                                                             A. Begen
Internet-Draft                                             Cisco Systems
Intended status:  Standards Track                          March 4, 2009
Expires:  September 5, 2009

                RTP Payload Format for MPEG2-TS Preamble

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 5, 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.

Begen                   Expires September 5, 2009               [Page 1]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009


   Demultiplexing and decoding an MPEG2 Transport Stream (MPEG2-TS)
   requires the knowledge of specific information about the transport
   stream, which we refer to as the MPEG2-TS Preamble.  While this
   information is spread over different locations throughout the
   transport stream and can be eventually assembled after some time a
   receiver started receiving the MPEG2-TS, the time it takes to
   retrieve all this information (especially in multicast environments)
   may be long.  Instead, having this information readily available as a
   Preamble and sending the Preamble to a receiver that will shortly
   start receiving the transport stream will virtually eliminate the
   waiting time and let the receiver start processing/decoding the
   MPEG2-TS sooner.  In this document, we give an overview of the
   MPEG2-TS and the delay components in video systems, and motivate the
   need for constructing and using the MPEG2-TS Preamble for rapidly
   synchronizing with the source stream in RTP multicast sessions.  We
   also define and register the RTP payload format for the MPEG2-TS

Begen                   Expires September 5, 2009               [Page 2]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  6
   3.  Elements of Delay in Video Systems . . . . . . . . . . . . . .  7
     3.1.  Overview of MPEG-2 Transport Streams . . . . . . . . . . .  7
     3.2.  Key Information Latency in Video Applications  . . . . . .  8
       3.2.1.  PSI (PAT/CAT/PMT) Acquisition Delay  . . . . . . . . .  8
       3.2.2.  Random Access Point Acquisition Delay  . . . . . . . .  9
     3.3.  Buffering Delays in Video Applications . . . . . . . . . . 10
       3.3.1.  Network-Related Buffering Delays . . . . . . . . . . . 10
       3.3.2.  Application-Related Buffering Delays . . . . . . . . . 11
   4.  Packet Format  . . . . . . . . . . . . . . . . . . . . . . . . 12
   5.  Payload Format Parameters  . . . . . . . . . . . . . . . . . . 14
     5.1.  Media Type Registration  . . . . . . . . . . . . . . . . . 14
       5.1.1.  Registration of audio/mpeg2-ts-preamble  . . . . . . . 14
       5.1.2.  Registration of video/mpeg2-ts-preamble  . . . . . . . 14
       5.1.3.  Registration of text/mpeg2-ts-preamble . . . . . . . . 14
       5.1.4.  Registration of application/mpeg2-ts-preamble  . . . . 14
     5.2.  Mapping to SDP Parameters  . . . . . . . . . . . . . . . . 14
       5.2.1.  Offer-Answer Model Considerations  . . . . . . . . . . 15
       5.2.2.  Declarative Considerations . . . . . . . . . . . . . . 15
   6.  Session Description Protocol (SDP) Signaling . . . . . . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     10.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22

Begen                   Expires September 5, 2009               [Page 3]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

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 is ubiquitous in
   broadcast applications over both terrestrial and satellite networks.
   Both Advanced Television Systems Committee (ATSC) in North America
   and Digital Video Broadcasting (DVB) in Europe use MPEG2-TS in their
   standards.  MPEG2-TS has been standardized by both ISO and ITU
   [MPEG2TS].  While MPEG2-TS was originally limited to carry MPEG-2
   encoded content, the specification was later extended to cover MPEG-
   4/AVC audio/video encoding standards as well.

   Due to the inherent design of MPEG2-TS, a receiver must first acquire
   certain information before demultiplexing and decoding an incoming
   MPEG2-TS.  As will be explained in Section 3.1, this information
   resides in the transport stream.  However, it is often not contiguous
   and is usually dispersed over a large period.  Thus, a receiver
   starting to receive an MPEG2-TS at a random location will have to
   wait until the whole required information shows up in the received
   data.  In multicast applications, since the joining receivers do not
   have any control over what point in the flow is currently being
   transmitted, their waiting times will vary.  This problem has been
   identified and examined in detail in
   [I-D.versteeg-avt-rapid-synchronization-for-rtp], where the time lag
   before a receiver can usefully consume the multicast data is referred
   to as the Synchronization Delay.  Section 3 provides an overview of
   the delay components in video systems that contribute to the
   synchronization delay.

   [I-D.versteeg-avt-rapid-synchronization-for-rtp] refers to the
   information that must first be acquired before starting to process
   any data sent in the multicast session as the Key Information.  In
   this document, we refer to the subset of the key information that is
   related to the MPEG2-TS as the MPEG2-TS Preamble.

   For multicast applications running over RTP,
   [I-D.versteeg-avt-rapid-synchronization-for-rtp] proposes an approach
   where an auxiliary unicast RTP session is established between a
   retransmission server and the joining RTP receiver.  Over this
   unicast RTP session, the retransmission server provides the key
   information the RTP receiver needs to rapidly synchronize with the
   multicast session.  If the source stream in the RTP multicast session
   is carrying an MPEG2-TS, the key information will comprise the
   MPEG2-TS Preamble as well.  For its proper transmission from the
   retransmission server to the joining RTP receiver, a new RTP payload

Begen                   Expires September 5, 2009               [Page 4]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

   format has to be defined for the MPEG2-TS Preamble.  This document
   defines and registers this payload format.

Begen                   Expires September 5, 2009               [Page 5]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

2.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

Begen                   Expires September 5, 2009               [Page 6]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

3.  Elements of Delay in Video Systems

   For typical multicast-based video delivery systems, the multicast
   switching delay (time required to leave the previous multicast
   session and join the new session) is not the primary contributor to
   the overall synchronization delay.  The multicast flows are typically
   already present at the edge or deep in the network, the propagation
   delays for join operations are modest, and the multicast routers can
   typically process the Join and Leave messages quickly.  Even if the
   edge multicast router is not currently a member of the requested
   multicast session, the multicast routing control messages propagate
   through the network rapidly and trees are built without experiencing
   large delays.  Even in cases where a number of tree branches need to
   be built to the edge multicast router, this cost is frequently
   amortized over a large number of receivers such that only the first
   receiver joining the group experiences the increased delay.  Further,
   this delay can be eliminated at the cost of extra bandwidth in the
   network core by having the edge routers do static joins for the set
   of sessions they expect receivers to be interested in.  These
   techniques usually provide a well-bounded multicast switching delay.

   Once the join operation completes and a receiver starts receiving
   media content for the first time in a multicast session, it often
   experiences a considerable amount of key information latency and
   buffering delays.  In the following subsections, we discuss the
   details of these delay elements using MPEG2-TS as the motivating use

3.1.  Overview of MPEG-2 Transport Streams

   MPEG2-TS is a container format that describes the schema of the audio
   and video content and the in-band control information.  Prior to
   multiplexing, an audio and a video encoder output audio and video
   Elementary Streams (ES), respectively.  The ES streams are then
   packetized to form the Packetized Elementary Streams (PES).  The
   resulting elements are called PES packets.  A transport stream (TS)
   encapsulates several PES streams and other data, and carries them in
   TS packets.  The RTP payload format for carrying TS packets in an RTP
   stream is specified in [RFC2250].  In addition to the audio and video
   ES streams, there are ES streams that carry control data.

   Program Specific Information (PSI) consists of metadata carried in
   the transport stream.  PSI includes Program Association Table (PAT),
   Conditional Access Table (CAT) and Program Map Table (PMT).  A PAT
   has information about all the programs carried in the transport
   stream.  It lists the 13-bit Program IDs (PID) for all the PMTs,
   associating them with the individual programs.  Each of the ES
   streams of a particular program in the transport stream also has the

Begen                   Expires September 5, 2009               [Page 7]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

   same PID values.  This way, a decoder at the receiving side can
   extract the desired TS packets from the transport stream by checking
   their PID values.  If the transport stream is not a Multi-Program
   Transport Stream (MPTS), but rather it is a Single-Program Transport
   Stream (SPTS), all the ES streams in the transport stream correspond
   to a single program.

   CAT defines the type of the scrambling used (either at the PES or TS
   level), and identifies all the PID values of the TS packets that
   contain the Entitlement Management Messages (EMM).  In addition to
   containing the PID values of each ES stream associated with a
   particular program, the PMT table also includes private data
   associated with the program such as the PID value of the packet
   containing the Entitlement Control Messages (ECM).  The data
   contained in the EMM and ECM messages are vital in descrambling
   encrypted content.  Note that PSI is carried in clear and is never
   scrambled so that a receiver which just started receiving the
   transport stream can process the PSI.  The PAT, CAT and PMT tables
   must be parsed by the decoder in order to find the ES streams,
   private data as well as the encryption information for a given

   MPEG2-TS produces output that is synchronized to a common clock
   across all the ESs in the multiplex.  To assist the audio and video
   decoders, programs periodically provide a Program Clock Reference
   (PCR) value in the transport stream.  PCR values are embedded in the
   TS adaptation field headers and are inserted by the encoder at least
   every 100 ms.  A PCR timestamp represents the value of the encoder's
   system clock when it was sampled.  The system clock is driven by a
   local 27 MHz oscillator.

   PCR is extremely important in native MPEG-2 transport to keep the
   decoders synchronized.  For example, the periodically sent Decoding
   Timestamps (DTS) and Presentation Timestamps (PTS) are specified
   relative to the PCR value and the decoders use the PCR value as the
   basis for a master clock during decoding and playout.

3.2.  Key Information Latency in Video Applications

   We classify the key information latency into two categories.

3.2.1.  PSI (PAT/CAT/PMT) Acquisition Delay

   As we discussed in Section 3.1, the video (and the audio as well) in
   an MPEG2-TS is self describing, and the receiver must parse certain
   control information in the PAT, CAT and PMT tables (i.e., PSI)
   contained in the transport stream in order to know how to parse the
   rest of the stream (i.e., to find the audio and video elementary

Begen                   Expires September 5, 2009               [Page 8]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

   streams, private data and the encryption information for a given

   Many video services employ content encryption and the encryption keys
   must be parsed as well for decrypting the content.  In order to
   enable various system elements to process video effectively, certain
   portions of the stream are left unencrypted.  The PAT/PMT tables are
   always in the clear.  The structure of the ECMs is also in the clear,
   although the ECM content which contains keying material is encrypted.
   The PSI information is repeated periodically in the transport stream,
   thus, when a receiver joins the multicast session, it needs to wait
   until the next time PSI is sent in the transport stream.

3.2.2.  Random Access Point Acquisition Delay

   Conventional MPEG2 video encoders encode the video content in Groups
   of Pictures (GoP).  Each GoP is encoded independently from other GoPs
   and starts with an intra-coded frame (I-frame) that does not have any
   reference to other frames in the same GoP, i.e., an I-frame contains
   the representation of an entire picture and can be decoded
   independently.  Thus, the start of an I-frame is said to be a Random
   Access Point (RAP).

   On the other hand, due to the temporal compression, rest of the
   frames in the same GoP may have references to the I-frame or to other
   frames in the same GoP.  Due to this interdependency among the
   frames, one generally has to receive certain elements of the GoP
   prior to decoding or rendering any part of the GoP.  For example, the
   decoder can decode a frame that is dependent on two other frames only
   after these two frames are decoded.

   Usually, GoP durations are between 500 ms and one second.  However,
   more advanced codecs may use longer GoPs to gain from the encoding
   efficiency.  When a receiver joins the multicast session, it needs to
   wait until the next RAP shows up in the multicast stream before it
   can start decoding.  Since the frame that is currently being
   multicast does not depend on the join time, the average time a
   receiver waits for RAP, i.e., the average RAP acquisition delay, is
   approximately equal to half of the GoP duration.  Hence, for longer
   GoPs, the RAP acquisition delay is proportionally longer.

   Advanced Video Coding (AVC) (also called MPEG4 part 10) compression
   is very similar to MPEG2 compression.  It has a few more compression
   tools available, including Hierarchical GoPs.  In a hierarchical GoP,
   the dependent frames of a GoP may reference the key frame at the
   start of this GoP or the key frame at the start of the next GoP.
   This additional dependency causes a longer RAP acquisition delay, as
   the decoder must receive two I-frames (spread between two logical

Begen                   Expires September 5, 2009               [Page 9]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

   GoPs) before decoding can commence.  In an Open GOP, a frame in one
   GoP may refer to a frame in a previous GoP.  AVC also has the ability
   to insert Instantaneous Decoding Refresh (IDR) frames.  Frames that
   follow an IDR frame cannot reference frames that precede an IDR
   frame.  IDR frames are useful for editing AVC streams, but are
   typically do not appear often enough in streaming video to be useful
   in a stream synchronization context.

   Note that in order for an intermediary network element such as a
   retransmission server to find the random access points in the video
   stream (e.g., I-frames), the necessary structural information must be
   in the clear if the intermediary is not in possession of the
   necessary keys.

3.3.  Buffering Delays in Video Applications

   We classify the buffering delays into two categories.

3.3.1.  Network-Related Buffering Delays

   In general, multicast-based video applications use an unreliable
   underlying transport protocol such as UDP [RFC0768] to distribute the
   content to a large number of receivers.  This is largely due to the
   fact that these applications are one way in nature and providing
   closed-loop reliability does not scale well when the number of
   receivers is large or the acceptable playout delay is small, or both.
   Rather, if there is a need for reliability, the applications may
   employ one or more loss-repair methods to recover the packets missing
   at each receiver (The Reliable Multicast Transport Working Group has
   several standardized solutions for this problem.  Refer to
   [I-D.ietf-rmt-pi-norm-revised] for details).  For example, Forward
   Error Correction (FEC) may be used proactively and/or on-demand to
   provide reliable transmission to a potentially very large multicast
   group in a scalable manner [I-D.ietf-fecframe-framework].  Similarly,
   retransmissions may be used in RTP-based multicast sessions where the
   retransmissions can be handled by local repair servers rather than
   the source itself [I-D.ietf-avt-rtcpssm].  However, regardless of the
   type of the loss-repair method(s) adopted by an application, loss-
   recovery operations always require additional buffering at the
   receiver side.  The amount of buffering increases with the FEC block
   size when FEC is used, and with the round-trip time between the
   receiver and the local repair server when retransmission is used.

   Audio and video decoders demand almost jitter-free content.  If any
   jitter is introduced during the transmission in the network or due to
   the loss-repair methods, the jitter has to be smoothed out before the
   content is fed to the decoder.  This is called de-jittering and it
   usually adds up to the buffering delay.

Begen                   Expires September 5, 2009              [Page 10]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

3.3.2.  Application-Related Buffering Delays

   The application buffering requirements for MPEG-encoded content are
   quite rigorous, particularly for the MPEG-based video applications.
   Video compression devices apply more bits to represent certain scenes
   than they do for other scenes.  A very complex scene (individual
   picture) requires considerably more information than a simple scene.
   Furthermore, pictures that are entirely intra-coded, e.g., I-frames,
   consume more bits compared to pictures that make use of predictive
   coding.  Each scene is shown by the decoder at a certain fixed frame
   rate (e.g., 24 fps or 30 fps).  Since some scenes are comprised more
   bits than other scenes, the output rate of the decoder buffer is
   usually variable.  However, the network flow is typically Constant
   Bit Rate (CBR) or Capped Variable Bit Rate (Capped VBR).  The net
   effect is that the input rate to the decoder buffer is close to
   constant, but the output rate is highly variable.

   The video encoders keep track of the decoder buffer size, and use
   this information to regulate the temporal compression.  This forces
   the decoder buffer to "breathe."  In order to avoid underflow, the
   decoder buffer must fill up to a certain level prior to starting to
   decode and play the content.  The decoder buffer size required to
   avoid underflow is dependent on the encoder, and the encoder signals
   the decoder buffering requirements in-band.  Typical decoder buffer
   requirements for MPEG2 content range from a few hundreds of
   milliseconds to a few seconds.  However, AVC/MPEG4 part 10 encoders
   usually tend to use more temporal compression, and thus require a
   larger buffer at the decoder side.  This consequently increases the
   buffering delays.

Begen                   Expires September 5, 2009              [Page 11]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

4.  Packet Format

   This section defines the MPEG2-TS Preamble packet format.

   The RTP header is formatted according to [RFC3550] with some further
   clarifications listed below:

   o  Marker (M) Bit:  This bit MAY be used to indicate the last packet
      carrying the MPEG2-TS Preamble information if there are more than
      one such packets.

      Editor's note:  This should be discussed.

   o  Payload Type:  The (dynamic) payload type for the MPEG2-TS
      Preamble packets is determined through out-of-band means.  Note
      that this document registers a new payload format for the MPEG2-TS
      Preamble packets (Refer to Section 5 for details).  According to
      [RFC3550], an RTP receiver that cannot recognize a payload type
      must discard it.  This provides backward compatibility.

   o  Sequence Number (SN):  The sequence number has the standard
      definition.  It MUST be one higher than the sequence number in the
      previously transmitted MPEG2-TS Preamble packet.  The initial
      value of the sequence number SHOULD be random (unpredictable)

   o  Timestamp (TS):  The timestamp SHALL be set to a time
      corresponding to the packet's transmission time.

   o  Synchronization Source (SSRC):  Per [RFC3550], the SSRC value
      SHOULD be chosen randomly with collision detection.  However,
      since the RTP session carrying MPEG2-TS Preamble has a short
      lifetime, using the same SSRC value with the source RTP session
      carrying the MPEG2-TS may also make sense.

      Editor's note:  This issue should be discussed.

   The payload has the structure depicted in Figure 1.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     :                              TBC                              :

             Figure 1: Format of the MPEG2-TS Preamble payload

Begen                   Expires September 5, 2009              [Page 12]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

      Editor's note:  The format of this message is TBD.

Begen                   Expires September 5, 2009              [Page 13]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

5.  Payload Format Parameters

   This section provides the media subtype registration for the MPEG2-TS

5.1.  Media Type Registration

   This registration is done using the template defined in [RFC4288] and
   following the guidance provided in [RFC3555].

5.1.1.  Registration of audio/mpeg2-ts-preamble


5.1.2.  Registration of video/mpeg2-ts-preamble


5.1.3.  Registration of text/mpeg2-ts-preamble


5.1.4.  Registration of application/mpeg2-ts-preamble


5.2.  Mapping to SDP Parameters

   Applications that are using RTP transport commonly use Session
   Description Protocol (SDP) [RFC4566] to describe their RTP sessions.
   The information that is used to specify the media types in an RTP
   session has specific mappings to the fields in an SDP description.
   In this section, we provide these mappings for the media subtype
   registered by this document ("mpeg2-ts-preamble").  Note that if an
   application does not use SDP to describe the RTP sessions, an
   appropriate mapping must be defined and used to specify the media
   types and their parameters for the control/description protocol
   employed by the application.

   The mapping of the media type specification for "mpeg2-ts-preamble"
   and its parameters in SDP is as follows:

   o  The media type (e.g., "application") goes into the "m=" line as
      the media name.

   o  The media subtype ("mpeg2-ts-preamble") goes into the "a=rtpmap"
      line as the encoding name.  The RTP clock rate parameter ("rate")
      also goes into the "a=rtpmap" line as the clock rate.

Begen                   Expires September 5, 2009              [Page 14]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

   o  The remaining required payload-format-specific parameters go into
      the "a=fmtp" line by copying them directly from the media type
      string as a semicolon-separated list of parameter=value pairs.

   SDP examples are provided in Section 6.

5.2.1.  Offer-Answer Model Considerations


5.2.2.  Declarative Considerations


Begen                   Expires September 5, 2009              [Page 15]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

6.  Session Description Protocol (SDP) Signaling

   This section provides an SDP [RFC4566] example.


Begen                   Expires September 5, 2009              [Page 16]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

7.  Security Considerations


Begen                   Expires September 5, 2009              [Page 17]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

8.  IANA Considerations

   New media subtypes are subject to IANA registration.  For the
   registration of the payload format and its parameters introduced in
   this document, refer to Section 5.

Begen                   Expires September 5, 2009              [Page 18]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

9.  Acknowledgments


Begen                   Expires September 5, 2009              [Page 19]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

10.  References

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

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288, December 2005.

   [RFC3555]  Casner, S. and P. Hoschka, "MIME Type Registration of RTP
              Payload Formats", RFC 3555, July 2003.

10.2.  Informative References

   [MPEG2TS]  ITU-T H.222.0, "Generic Coding of Moving Pictures and
              Associated Audio Information: Systems", May 2006.

              Steeg, B., Begen, A., and T. Caenegem, "Unicast-Based
              Rapid Synchronization with RTP Multicast Sessions",
              draft-versteeg-avt-rapid-synchronization-for-rtp-01 (work
              in progress), November 2008.

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

              Ott, J., "RTCP Extensions for Single-Source Multicast
              Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17
              (work in progress), January 2008.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

              Adamson, B., Bormann, C., London, U., and J. Macker,
              "NACK-Oriented Reliable Multicast Protocol",
              draft-ietf-rmt-pi-norm-revised-08 (work in progress),
              December 2008.

Begen                   Expires September 5, 2009              [Page 20]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

              Watson, M., "Forward Error Correction (FEC) Framework",
              draft-ietf-fecframe-framework-03 (work in progress),
              October 2008.

Begen                   Expires September 5, 2009              [Page 21]

Internet-Draft  RTP Payload Format for MPEG2-TS Preamble      March 2009

Author's Address

   Ali Begen
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134

   Email:  abegen@cisco.com

Begen                   Expires September 5, 2009              [Page 22]