RFC 2038 (rfc2038) - Page 3 of 11


RTP Payload Format for MPEG1/MPEG2 Video



Alternative Format: Original Text Document



RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996


   Much interest in the MPEG community is in the use of one of the MPEG
   System encodings, and hence, in Section 2 we propose encapsulations
   of MPEG1 System streams and MPEG2 Transport and Program Streams with
   RTP.  This profile supports the full semantics of MPEG System and
   offers basic interoperability among all four end-system types.

   When operating only among internet-based end-systems (i.e., TAES and
   RAES) a payload format that provides greater compatibility with the
   Internet architecture is desired, deferring some of the system issues
   to other protocols being defined in the Internet community (such as
   the MMUSIC WG).  In Section 3 we propose an encapsulation of
   compressed video and audio data (referred to in MPEG documentation as
   "Elementary Streams" (ES)) complying with either MPEG1 or MPEG2.
   Here, neither of the System standards of MPEG1 or MPEG2 are utilized.
   The ES's are directly encapsulated with RTP.

   Throughout this specification, we make extensive use of MPEG
   terminology.  The reader should consult the primary MPEG references
   for definitive descriptions of this terminology.

2. Encapsulation of MPEG System and Transport Streams

   Each RTP packet will contain a timestamp derived from the sender's
   90KHz clock reference.  This clock is synchronized to the system
   stream Program Clock Reference (PCR) or System Clock Reference (SCR)
   and represents the target transmission time of the first byte of the
   packet payload.  The RTP timestamp will not be passed to the MPEG
   decoder.  This use of the timestamp is somewhat different than
   normally is the case in RTP, in that it is not considered to be the
   media display or presentation timestamp. The primary purposes of the
   RTP timestamp will be to estimate and reduce any network-induced
   jitter and to synchronize relative time drift between the transmitter
   and receiver.

   For MPEG2 Transport Streams the RTP payload will contain an integral
   number of MPEG transport packets.  To avoid end system
   inefficiencies, data from multiple small MTS packets (normally fixed
   in size at 188 bytes) are aggregated into a single RTP packet.  The
   number of transport packets contained is computed by dividing RTP
   payload length by the length of an MTS packet (188).

   For MPEG2 Program streams and MPEG1 system streams there are no
   packetization restrictions; these streams are treated as a packetized
   stream of bytes.







Hoffman, et. al.            Standards Track