RTP Payload Format for MPEG1/MPEG2 Video
RFC 2038

Document Type RFC - Proposed Standard (October 1996; No errata)
Obsoleted by RFC 2250
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2038 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         D. Hoffman
Request for Comments: 2038                                   G. Fernando
Category: Standards Track                         Sun Microsystems, Inc.
                                                                V. Goyal
                                                  Precept Software, Inc.
                                                            October 1996

                RTP Payload Format for MPEG1/MPEG2 Video

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.


   This memo describes a packetization scheme for MPEG video and audio
   streams.  The scheme proposed can be used to transport such a video
   or audio flow over the transport protocols supported by RTP.  Two
   approaches are described. The first is designed to support maximum
   interoperability with MPEG System environments.  The second is
   designed to provide maximum compatibility with other RTP-encapsulated
   media streams and future conference control work of the IETF.

1. Introduction

   ISO/IEC JTC1/SC29 WG11 (also referred to as the MPEG committee) has
   defined the MPEG1 standard (ISO/IEC 11172)[1] and the MPEG2 standard
   (ISO/IEC 13818)[2].  This memo describes a packetization scheme to
   transport MPEG video and audio streams using the Real-time Transport
   Protocol (RTP), version 2 [3, 4].

   The MPEG1 specification is defined in three parts: System, Video and
   Audio.  It is designed primarily for CD-ROM-based applications, and
   is optimized for approximately 1.5 Mbits/sec combined data rates. The
   video and audio portions of the specification describe the basic
   format of the video or audio stream.  These formats define the
   Elementary Streams (ES).  The MPEG1 System specification defines an
   encapsulation of the ES that contains Presentation Time Stamps (PTS),
   Decoding Time Stamps and System Clock references, and performs
   multiplexing of MPEG1 compressed video and audio ES's with user data.

Hoffman, et. al.            Standards Track                     [Page 1]
RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996

   The MPEG2 specification is structured in a similar way. However, it
   hasn't been restricted only to CD-ROM applications. The MPEG2 System
   specification defines two system stream formats:  the MPEG2 Transport
   Stream (MTS) and the MPEG2 Program Stream (MPS).  The MTS is tailored
   for communicating or storing one or more programs of MPEG2 compressed
   data and also other data in relatively error-prone environments. The
   MPS is tailored for relatively error-free environments.

   We seek to achieve interoperability among 4 types of end-systems in
   the following specification. The 4 types are:

        1. Transmitting Interworking Unit (TIU)

           Receives MPEG information from a native MTS system for
           distribution over packet networks using a native RTP-based
           system layer (such as an IP-based internetwork). Examples:
           real-time encoder, MTS satellite link to Internet, video
           server with MTS-encoded source material.

        2. Receiving Interworking Unit (RIU)

           Receives MPEG information in real time from an RTP-based
           network for forwarding to a native MTS environment.
           Examples: Internet-based video server to MTS-based cable
           distribution plant.

        3. Transmitting Internet End-System (TAES)

           Transmits MPEG information generated or stored within the
           internet end-system itself, or received from internet-based
           computer networks.  Example: video server.

        4. Receiving Internet End-System (RAES)

           Receives MPEG information over an RTP-based internet for
           consumption at the internet end-system or forwarding to
           traditional computer network.  Example: desktop PC or
           workstation viewing training video.

   Each of the 2 types of transmitters must work with each of the 2
   types of receivers.  Because it is probable that the TAES, and
   certain that the RAES, will be based on existing and planned
   internet-connected computers, it is highly desirable for the
   interoperable protocol to be based on RTP.

   Because of the range of applications that might employ MPEG streams,
   we propose to define two payload formats.

Hoffman, et. al.            Standards Track                     [Page 2]
RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996
Show full document text