[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                    Casner-Packet Design
Internet Draft                                          Gentric-Philips
Document: draft-gentric-avt-profile-00.txt                 January 2001
                                                      Expires July 2001

                 RTP profile for generic media packets

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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

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

   This specification is a product of the Audio/Video Transport working
   group within the Internet Engineering Task Force and ISO/IEC MPEG-4
   ad hoc group on MPEG-4 over Internet. Comments are solicited and
   should be addressed to the working group's mailing list at rem-
   conf@es.net and/or the authors.


   This document describes a RTP profile for transporting generic media
   packet properties using bits in the RTP payload type RTP header
   field. One typical usage of this profile is for the transport of
   MPEG-4 but the scheme is general enough to be suitable for many
   media streams.

1. Introduction

   Following RFC 1889 [1, section 5.3] this draft specifies a RTP
   profile were bits of the RTP header payload type field are used to
   transport generic media packet properties. One application of this
   profile is the transport of MPEG-4 encoded data streams.

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

Casner, Gentric, Perkins                                             1

                RTP profile for generic media packets    January 2001

2. M bit signification for this profile

   As widely used by many RTP payload formats the M bit is set to 1 to
   indicate that the RTP packet transports at least one complete media
   frame or the last fragment of a media frame. For decoders that
   cannot start decoding before a full frame as been received this
   information is useful to trigger decoding. When frames are
   fragmented across several RTP packets this bit is also useful for
   the indication of frame boundaries.

3. Payload type field for this profile

   The RTP header payload type field has 7 bits. This profile assigns a
   specific signification for the first 2 bits of this field (therefore
   restricting the number of payload types to 32).

   The first 2 bits of the payload type defined by this profile are:

   RAP: Random Access Point information. When this bit (RAP) is set (1)
   it indicates that the RTP packet transports a media frame or
   fragment of frame that carries information suitable for Random
   Access i.e. a section of the stream from which decoding can start,
   whatever packets where sent before (or lost). This information is
   especially useful for media streams compressed using correlation in
   the time domain such as MPEG video.

   FS: Frame Start information. When this bit (FS) is set (1) it
   indicates that the RTP packet transports at least a complete media
   frame (or encoded frame) or the first fragment of frame. This bit is
   complementary to the M bit for several reasons:

   Firstly, in case the packet transporting the last fragment of a
   frame (M bit set to 1) is lost the frame boundary information would
   be lost.

   Secondly with this profile a packet for which neither the FS bit nor
   the M bit are set is directly identifiable by a receiver as a middle
   fragment of a media frame, which in some cases can be immediately

   Finally for some codecs and for the MPEG-4 system framework,
   information is attached to each encoded frame i.e. Access Unit for
   MPEG-4 system. Examples of such information for MPEG-4 system are
   the degradation priority, the Object Clock Reference, etc. The FS
   bit can then be used (in a payload specific manner) to indicate the
   presence of this information, typically located in the first bits of
   the RTP packet payload.

4. Table of values

Casner, Gentric, Perkins                                             2

                RTP profile for generic media packets    January 2001

   The following table summarizes the 8 possible cases corresponding to
   the values of the M, RAP and FS bits:

   000: fragment
   001: first fragment
   010: fragment carrying RAP information
   011: first fragment carrying RAP information
   100: last fragment
   101: full media frame that is not a RAP
   110: last fragment carrying RAP information
   111: full media frame that is a RAP

5. References

   [1] Schulzrinne, Casner, Frederick, Jacobson RTP: A Transport
   Protocol for Real Time
   Applications  RFC 1889, Internet Engineering Task Force, January

   [2] S. Bradner, Key words for use in RFCs to Indicate Requirement
   Levels, RFC 2119,
   March 1997.

6. Authors' Addresses

   Stephen L. Casner
   Packet Design, Inc.
   66 Willow Place
   Menlo Park, CA 94025

   Philippe Gentric
   Philips Digital Networks
   22 Avenue Descartes
   94453 Limeil-Brevannes CEDEX
   e-mail: philippe.gentric@philips.com

   Colin Perkins
   USC Information Sciences Institute
   4350 N. Fairfax Drive #620
   Arlington, VA 22203
   e-mail: csp@isi.edu

Casner, Gentric, Perkins                                             3