Internet Engineering Task Force Casner-Packet Design Internet Draft Gentric-Philips Perkins-ISI 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 progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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. Abstract 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 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 discarded. 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 1996. [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 USA casner@acm.org Philippe Gentric Philips Digital Networks 22 Avenue Descartes 94453 Limeil-Brevannes CEDEX France e-mail: philippe.gentric@philips.com Colin Perkins USC Information Sciences Institute 4350 N. Fairfax Drive #620 Arlington, VA 22203 USA e-mail: csp@isi.edu Casner, Gentric, Perkins 3