rfc3640.txt

完整的RTP RTSP代码库

Network Working Group                                    J. van der Meer
Request for Comments: 3640                           Philips Electronics
Category: Standards Track                                      D. Mackie
                                                          Apple Computer
                                                          V. Swaminathan
                                                   Sun Microsystems Inc.
                                                               D. Singer
                                                          Apple Computer
                                                              P. Gentric
                                                     Philips Electronics
                                                           November 2003


     RTP Payload Format for Transport of MPEG-4 Elementary Streams

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.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29
   WG11) is a working group in ISO that produced the MPEG-4 standard.
   MPEG defines tools to compress content such as audio-visual
   information into elementary streams.  This specification defines a
   simple, but generic RTP payload format for transport of any non-
   multiplexed MPEG-4 elementary stream.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Carriage of MPEG-4 Elementary Streams Over RTP . . . . . . . .  4
       2.1.  Signaling by MIME Format Parameters  . . . . . . . . . .  4
       2.2.  MPEG Access Units  . . . . . . . . . . . . . . . . . . .  5
       2.3.  Concatenation of Access Units  . . . . . . . . . . . . .  5
       2.4.  Fragmentation of Access Units  . . . . . . . . . . . . .  6
       2.5.  Interleaving . . . . . . . . . . . . . . . . . . . . . .  6
       2.6.  Time Stamp Information . . . . . . . . . . . . . . . . .  7
       2.7.  State Indication of MPEG-4 System Streams  . . . . . . .  8
       2.8.  Random Access Indication . . . . . . . . . . . . . . . .  8



van der Meer, et al.        Standards Track                     [Page 1]

RFC 3640         Transport of MPEG-4 Elementary Streams    November 2003


       2.9.  Carriage of Auxiliary Information  . . . . . . . . . . .  8
       2.10. MIME Format Parameters and Configuring Conditional Field  8
       2.11. Global Structure of Payload Format . . . . . . . . . . .  9
       2.12. Modes to Transport MPEG-4 Streams  . . . . . . . . . . .  9
       2.13. Alignment with RFC 3016  . . . . . . . . . . . . . . . . 10
   3.  Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 10
       3.1.  Usage of RTP Header Fields and RTCP  . . . . . . . . . . 10
       3.2.  RTP Payload Structure  . . . . . . . . . . . . . . . . . 11
             3.2.1.  The AU Header Section  . . . . . . . . . . . . . 11
                     3.2.1.1.  The AU-header  . . . . . . . . . . . . 12
             3.2.2.  The Auxiliary Section . . . . . . . . . . . . .  14
             3.2.3.  The Access Unit Data Section . . . . . . . . . . 15
                     3.2.3.1.  Fragmentation. . . . . . . . . . . . . 16
                     3.2.3.2.  Interleaving . . . . . . . . . . . . . 16
                     3.2.3.3.  Constraints for Interleaving . . . . . 17
                     3.2.3.4.  Crucial and Non-Crucial AUs with
                               MPEG-4 System Data . . . . . . . . . . 20
       3.3.  Usage of this Specification. . . . . . . . . . . . . . . 21
             3.3.1.  General. . . . . . . . . . . . . . . . . . . . . 21
             3.3.2.  The Generic Mode . . . . . . . . . . . . . . . . 22
             3.3.3.  Constant Bit Rate CELP . . . . . . . . . . . . . 22
             3.3.4.  Variable Bit Rate CELP . . . . . . . . . . . . . 23
             3.3.5.  Low Bit Rate AAC . . . . . . . . . . . . . . . . 24
             3.3.6.  High Bit Rate AAC. . . . . . . . . . . . . . . . 25
             3.3.7.  Additional Modes . . . . . . . . . . . . . . . . 26
   4.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 27
       4.1.  MIME Type Registration . . . . . . . . . . . . . . . . . 27
       4.2.  Registration of Mode Definitions with IANA . . . . . . . 33
       4.3.  Concatenation of Parameters. . . . . . . . . . . . . . . 33
       4.4.  Usage of SDP . . . . . . . . . . . . . . . . . . . . . . 34
             4.4.1.  The a=fmtp Keyword . . . . . . . . . . . . . . . 34
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 34
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
   APPENDIX: Usage of this Payload Format. . .  . . . . . . . . . . . 36
   Appendix A.  Interleave Analysis . . . . . . . . . . . . . . . . . 36
   A.  Examples of Delay Analysis with Interleave. . .  . . . . . . . 36
       A.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . 36
       A.2.  De-interleaving and Error Concealment  . . . . . . . . . 36
       A.3.  Simple Group Interleave  . . . . . . . . . . . . . . . . 36
             A.3.1.  Introduction . . . . . . . . . . . . . . . . . . 36
             A.3.2.  Determining the De-interleave Buffer Size  . . . 37
             A.3.3.  Determining the Maximum Displacement . . . . . . 37
       A.4.  More Subtle Group Interleave . . . . . . . . . . . . . . 38
             A.4.1.  Introduction . . . . . . . . . . . . . . . . . . 38
             A.4.2.  Determining the De-interleave Buffer Size. . . . 38
             A.4.3.  Determining the Maximum Displacement . . . . . . 39
       A.5.  Continuous Interleave  . . . . . . . . . . . . . . . . . 39
             A.5.1.  Introduction . . . . . . . . . . . . . . . . . . 39



van der Meer, et al.        Standards Track                     [Page 2]

RFC 3640         Transport of MPEG-4 Elementary Streams    November 2003


             A.5.2.  Determining the De-interleave Buffer Size  . . . 40
             A.5.3.  Determining the Maximum Displacement . . . . . . 40
   References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
   Normative References . . . . . . . . . . . . . . . . . . . . . . . 41
   Informative References . . . . . . . . . . . . . . . . . . . . . . 41
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 43

1.  Introduction

   The MPEG Committee is Working Group 11 (WG11) in ISO/IEC JTC1 SC29
   that specified the MPEG-1, MPEG-2 and, more recently, the MPEG-4
   standards [1].  The MPEG-4 standard specifies compression of audio-
   visual data into, for example an audio or video elementary stream.
   In the MPEG-4 standard, these streams take the form of audio-visual
   objects that may be arranged into an audio-visual scene by means of a
   scene description.  Each MPEG-4 elementary stream consists of a
   sequence of Access Units; examples of an Access Unit (AU) are an
   audio frame and a video picture.

   This specification defines a general and configurable payload
   structure to transport MPEG-4 elementary streams, in particular
   MPEG-4 audio (including speech) streams, MPEG-4 video streams and
   also MPEG-4 systems streams, such as BIFS (BInary Format for Scenes),
   OCI (Object Content Information), OD (Object Descriptor) and IPMP
   (Intellectual Property Management and Protection) streams.  The RTP
   payload defined in this document is simple to implement and
   reasonably efficient.  It allows for optional interleaving of Access
   Units (such as audio frames) to increase error resiliency in packet
   loss.

   Some types of MPEG-4 elementary streams include "crucial" information
   whose loss cannot be tolerated.  However, RTP does not provide
   reliable transmission, so receipt of that crucial information is not
   assured.  Section 3.2.3.4 specifies how stream state is conveyed so
   that the receiver can detect the loss of crucial information and
   cease decoding until the next random access point has been received.
   Applications transmitting streams that include crucial information,
   such as OD commands, BIFS commands, or programmatic content such as
   MPEG-J (Java) and ECMAScript, should include random access points, at
   a suitable periodicity depending upon the probability of loss, in
   order to reduce stream corruption to an acceptable level.  An example
   is the carousel mechanism as defined by MPEG in ISO/IEC 14496-1 [1].

   Such applications may also employ additional protocols or services to
   reduce the probability of loss.  At the RTP layer, these measures
   include payload formats and profiles for retransmission or forward
   error correction (such as in RFC 2733 [10]), that must be employed



van der Meer, et al.        Standards Track                     [Page 3]

RFC 3640         Transport of MPEG-4 Elementary Streams    November 2003


   with due consideration to congestion control.  Another solution that
   may be appropriate for some applications is to carry RTP over TCP
   (such as in RFC 2326 [8], section 10.12).  At the network layer,
   resource allocation or preferential service may be available to
   reduce the probability of loss.  For a general description of methods
   to repair streaming media, see RFC 2354 [9].

   Though the RTP payload format defined in this document is capable of
   transporting any MPEG-4 stream, other, more specific, formats may
   exist, such as RFC 3016 [12] for transport of MPEG-4 video (ISO/IEC
   14496 [1] part 2).

   Configuration of the payload is provided to accommodate the
   transportation of any MPEG-4 stream at any possible bit rate.
   However, for a specific MPEG-4 elementary stream typically only very
   few configurations are needed.  So as to allow for the design of
   simplified, but dedicated receivers, this specification requires that
   specific modes be defined for transport of MPEG-4 streams.  This
   document defines modes for MPEG-4 CELP and AAC streams, as well as a
   generic mode that can be used to transport any MPEG-4 stream.  In the
   future, new RFCs are expected to specify additional modes for the
   transportation of MPEG-4 streams.

   The RTP payload format defined in this document specifies carriage of
   system-related information that is often equivalent to the
   information that may be contained in the MPEG-4 Sync Layer (SL) as
   defined in MPEG-4 Systems [1].  This document does not prescribe how
   to transcode or map information from the SL to fields defined in the
   RTP payload format.  Such processing, if any, is left to the
   discretion of the application.  However, to anticipate the need for
   the transportation of any additional system-related information in
   the future, an auxiliary field can be configured that may carry any
   such data.

   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 BCP 14, RFC 2119 [4].

2.  Carriage of MPEG-4 Elementary Streams over RTP

2.1.  Signaling by MIME Format Parameters

   With this payload format, a single MPEG-4 elementary stream can be
   transported.  Information on the type of MPEG-4 stream carried in the
   payload is conveyed by MIME format parameters, as in an SDP [5]
   message or by other means (see section 4).  These MIME format
   parameters specify the configuration of the payload.  To allow for
   simplified and dedicated receivers, a MIME format parameter is



van der Meer, et al.        Standards Track                     [Page 4]

RFC 3640         Transport of MPEG-4 Elementary Streams    November 2003


   available to signal a specific mode of using this payload.  A mode
   definition MAY include the type of MPEG-4 elementary stream, as well
   as the applied configuration, so as to avoid the need for receivers
   to parse all MIME format parameters.  The applied mode MUST be
   signaled.

2.2.  MPEG Access Units

   For carriage of compressed audio-visual data, MPEG defines Access
   Units.  An MPEG Access Unit (AU) is the smallest data entity to which
   timing information is attributed.  In the case of audio, an Access
   Unit may represent an audio frame and in the case of video, a
   picture.  MPEG Access Units are octet-aligned by definition.  If, for
   example, an audio frame is not octet-aligned, up to 7 zero-padding
   bits MUST be inserted at the end of the frame to achieve the octet-
   aligned Access Units, as required by the MPEG-4 specification.
   MPEG-4 decoders MUST be able to decode AUs in which such padding is
   applied.

   Consistent with the MPEG-4 specification, this document requires that
   each MPEG-4 part 2 video Access Unit include all the coded data of a
   picture, any video stream headers that may precede the coded picture
   data, and any video stream stuffing that may follow it, up to but not
   including the startcode indicating the start of a new video stream or
   the next Access Unit.

2.3.  Concatenation of Access Units

   Frequently it is possible to carry multiple Access Units in one RTP
   packet.  This is particularly useful for audio; for example, when AAC
   is used for encoding a stereo signal at 64 kbits/sec, AAC frames
   contain on average, approximately 200 octets.  On a LAN with a 1500
   octet MTU, this would allow an average of 7 complete AAC frames to be
   carried per RTP packet.

   Access Units may have a fixed size in octets, but a variable size is
   also possible.  To facilitate parsing in the case of multiple
   concatenated AUs in one RTP packet, the size of each AU is made known
   to the receiver.  When concatenating in the case of a constant AU
   size, this size is communicated "out of band" through a MIME format
   parameter.  When concatenating in case of variable size AUs, the RTP
   payload carries "in band" an AU size field for each contained AU.

   In combination with the RTP payload length, the size information
   allows the RTP payload to be split by the receiver back into the
   individual AUs.





van der Meer, et al.        Standards Track                     [Page 5]

RFC 3640         Transport of MPEG-4 Elementary Streams    November 2003


   To simplify the implementation of RTP receivers, it is required that