rfc3640.txt

完整的RTP RTSP代码库

   when multiple AUs are carried in an RTP packet, each AU MUST be
   complete, i.e., the number of AUs in an RTP packet MUST be integral.

   In addition, an AU MUST NOT be repeated in other RTP packets; hence
   repetition of an AU is only possible when using a duplicate RTP
   packet.

2.4.  Fragmentation of Access Units

   MPEG allows for very large Access Units.  Since most IP networks have
   significantly smaller MTU sizes, this payload format allows for the
   fragmentation of an Access Unit over multiple RTP packets.  Hence,
   when an IP packet is lost after IP-level fragmentation, only an AU
   fragment may get lost instead of the entire AU.  To simplify the
   implementation of RTP receivers, an RTP packet SHALL either carry one
   or more complete Access Units or a single fragment of one AU, i.e.,
   packets MUST NOT contain fragments of multiple Access Units.

2.5.  Interleaving

   When an RTP packet carries a contiguous sequence of Access Units, the
   loss of such a packet can result in a "decoding gap" for the user.
   One method of alleviating this problem is to allow for the Access
   Units to be interleaved in the RTP packets.  For a modest cost in
   latency and implementation complexity, significant error resiliency
   to packet loss can be achieved.

   To support optional interleaving of Access Units, this payload format
   allows for index information to be sent for each Access Unit.  After
   informing receivers about buffer resources to allocate for de-
   interleaving, the RTP sender is free to choose the interleaving
   pattern without propagating this information a priori to the
   receiver(s).  Indeed, the sender could dynamically adjust the
   interleaving pattern based on the Access Unit size, error rates, etc.
   The RTP receiver does not need to know the interleaving pattern used;
   it only needs to extract the index information of the Access Unit and
   insert the Access Unit into the appropriate sequence in the decoding
   or rendering queue.  An example of interleaving is given below.












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


   For example, if we assume that an RTP packet contains 3 AUs, and that
   the AUs are numbered 0, 1, 2, 3, 4, and so forth, and if an
   interleaving group length of 9 is chosen, then RTP packet(i) contains
   the following AU(n):

      RTP packet(0):  AU(0),  AU(3),  AU(6)
      RTP packet(1):  AU(1),  AU(4),  AU(7)
      RTP packet(2):  AU(2),  AU(5),  AU(8)
      RTP packet(3):  AU(9),  AU(12), AU(15)
      RTP packet(4):  AU(10), AU(13), AU(16)  Etc.

2.6.  Time Stamp Information

   The RTP time stamp MUST carry the sampling instant of the first AU
   (fragment) in the RTP packet.  When multiple AUs are carried within
   an RTP packet, the time stamps of subsequent AUs can be calculated if
   the frame period of each AU is known.  For audio and video, this is
   possible if the frame rate is constant.  However, in some cases it is
   not possible to make such a calculation (for example, for variable
   frame rate video, or for MPEG-4 BIFS streams carrying composition
   information).  To support such cases, this payload format can be
   configured to carry a time stamp in the RTP payload for each
   contained Access Unit.  A time stamp MAY be conveyed in the RTP
   payload only for non-first AUs in the RTP packet, and SHALL NOT be
   conveyed for the first AU (fragment), as the time stamp for the first
   AU in the RTP packet is carried by the RTP time stamp.

   MPEG-4 defines two types of time stamps: the composition time stamp
   (CTS) and the decoding time stamp (DTS).  The CTS represents the
   sampling instant of an AU, and hence the CTS is equivalent to the RTP
   time stamp.  The DTS may be used in MPEG-4 video streams that use
   bi-directional coding, i.e., when pictures are predicted in both
   forward and backward direction by using either a reference picture in
   the past, or a reference picture in the future.  The DTS cannot be
   carried in the RTP header.  In some cases, the DTS can be derived
   from the RTP time stamp using frame rate information; this requires
   deep parsing in the video stream, which may be considered
   objectionable.  If the video frame rate is variable, the required
   information may not even be present in the video stream.  For both
   reasons, the capability has been defined to optionally carry the DTS
   in the RTP payload for each contained Access Unit.

   To keep the coding of time stamps efficient, each time stamp
   contained in the RTP payload is coded as a difference.  For the CTS,
   the offset from the RTP time stamps is provided, and for the DTS, the
   offset from the CTS.





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


2.7.  State Indication of MPEG-4 System Streams

   ISO/IEC 14496-1 defines states for MPEG-4 system streams.  So as to
   convey state information when transporting MPEG-4 system streams,
   this payload format allows for the optional carriage in the RTP
   payload of the stream state for each contained Access Unit.  Stream
   states are used to signal "crucial" AUs that carry information whose
   loss cannot be tolerated and are also useful when repeating AUs
   according to the carousel mechanism defined in ISO/IEC 14496-1.

2.8.  Random Access Indication

   Random access to the content of MPEG-4 elementary streams may be
   possible at some but not all Access Units.  To signal Access Units
   where random access is possible, a random access point flag can
   optionally be carried in the RTP payload for each contained Access
   Unit.  Carriage of random access points is particularly useful for
   MPEG-4 system streams in combination with the stream state.

2.9.  Carriage of Auxiliary Information

   This payload format defines a specific field to carry auxiliary data.
   The auxiliary data field is preceded by a field that specifies the
   length of the auxiliary data, so as to facilitate the skipping of
   data without parsing it.  The coding of the auxiliary data is not
   defined in this document; instead, the format, meaning and signaling
   of auxiliary information is expected to be specified in one or more
   future RFCs.  Auxiliary information MUST NOT be transmitted until its
   format, meaning and signaling have been specified and its use has
   been signaled.  Receivers that have knowledge of the auxiliary data
   MAY decode the auxiliary data, but receivers without knowledge of
   such data MUST skip the auxiliary data field.

2.10.  MIME Format Parameters and Configuring Conditional Fields

   To support the features described in the previous sections, several
   fields are defined for carriage in the RTP payload.  However, their
   use strongly depends on the type of MPEG-4 elementary stream that is
   carried.  Sometimes a specific field is needed with a certain length,
   while in other cases such a field is not needed.  To be efficient in
   either case, the fields to support these features are configurable by
   means of MIME format parameters.  In general, a MIME format parameter
   defines the presence and length of the associated field.  A length of
   zero indicates absence of the field.  As a consequence, parsing of
   the payload requires knowledge of MIME format parameters.  The MIME
   format parameters are conveyed to the receiver via SDP [5] messages,
   as specified in section 4.4.1, or through other means.




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


2.11.  Global Structure of Payload Format

   The RTP payload following the RTP header, contains three octet-
   aligned data sections, of which the first two MAY be empty, see
   Figure 1.

         +---------+-----------+-----------+---------------+
         | RTP     | AU Header | Auxiliary | Access Unit   |
         | Header  | Section   | Section   | Data Section  |
         +---------+-----------+-----------+---------------+

                   <----------RTP Packet Payload----------->

            Figure 1: Data sections within an RTP packet

   The first data section is the AU (Access Unit) Header Section, that
   contains one or more AU-headers; however, each AU-header MAY be
   empty, in which case the entire AU Header Section is empty.  The
   second section is the Auxiliary Section, containing auxiliary data;
   this section MAY also be configured empty.  The third section is the
   Access Unit Data Section, containing either a single fragment of one
   Access Unit or one or more complete Access Units.  The Access Unit
   Data Section MUST NOT be empty.

2.12.  Modes to Transport MPEG-4 Streams

   While it is possible to build fully configurable receivers capable of
   receiving any MPEG-4 stream, this specification also allows for the
   design of simplified, but dedicated receivers, that are for example,
   capable of receiving only one type of MPEG-4 stream.  This is
   achieved by requiring that specific modes be defined in order to use
   this specification.  Each mode may define constraints for transport
   of one or more types of MPEG-4 streams, for instance on the payload
   configuration.

   The applied mode MUST be signaled.  Signaling the mode is
   particularly important for receivers that are only capable of
   decoding one or more specific modes.  Such receivers need to
   determine whether the applied mode is supported, so as to avoid
   problems with processing of payloads that are beyond the capabilities
   of the receiver.

   In this document several modes are defined for the transportation of
   MPEG-4 CELP and AAC streams, as well as a generic mode that can be
   used for any MPEG-4 stream.  In the future, new RFCs may specify
   other modes of using this specification.  However, each mode MUST be
   in full compliance with this specification (see section 3.3.7).




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


2.13.  Alignment with RFC 3016

   This payload can be configured as nearly identical to the payload
   format defined in RFC 3016 [12] for the MPEG-4 video configurations
   recommended in RFC 3016.  Hence, receivers that comply with RFC 3016
   can decode such RTP payload, provided that additional packets
   containing video decoder configuration (VO, VOL, VOSH) are inserted
   in the stream, as required by RFC 3016 [12].  Conversely, receivers
   that comply with the specification in this document SHOULD be able to
   decode payloads, names and parameters defined for MPEG-4 video in RFC
   3016 [12].  In this respect, it is strongly RECOMMENDED that the
   implementation provide the ability to ignore "in band" video decoder
   configuration packets that may be found in streams conforming to the
   RFC 3016 video payload.

   Note the "out of band" availability of the video decoder
   configuration is optional in RFC 3016 [12].  To achieve maximum
   interoperability with the RTP payload format defined in this
   document, applications that use RFC 3016 to transport MPEG-4 video
   (part 2) are recommended to make the video decoder configuration
   available as a MIME parameter.

3.  Payload Format

3.1.  Usage of RTP Header Fields and RTCP

   Payload Type (PT): The assignment of an RTP payload type for this
      packet format is outside the scope of this document; it is
      specified by the RTP profile under which this payload format is
      used, or signaled dynamically out-of-band (e.g., using SDP).

   Marker (M) bit: The M bit is set to 1 to indicate that the RTP packet
      payload contains either the final fragment of a fragmented Access
      Unit or one or more complete Access Units.

   Extension (X) bit: Defined by the RTP profile used.

   Sequence Number: The RTP sequence number SHOULD be generated by the
      sender in the usual manner with a constant random offset.

   Timestamp: Indicates the sampling instant of the first AU contained
      in the RTP payload.  This sampling instant is equivalent to the
      CTS in the MPEG-4 time domain.  When using SDP, the clock rate of
      the RTP time stamp MUST be expressed using the "rtpmap" attribute.
      If an MPEG-4 audio stream is transported, the rate SHOULD be set
      to the same value as the sampling rate of the audio stream.  If an
      MPEG-4 video stream is transported, it is RECOMMENDED that the
      rate be set to 90 kHz.



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


   In all cases, the sender SHALL make sure that RTP time stamps are
   identical only if the RTP time stamp refers to fragments of the same
   Access Unit.

   According to RFC 3550 [2] (section 5.1), it is RECOMMENDED that RTP
   time stamps start at a random value for security reasons.  This is
   not an issue for synchronization of multiple RTP streams.  However,
   when streams from multiple sources are to be synchronized (for