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