rfc3016.txt

最新的RFC

   parameter "cpresent" corresponds to the muxConfigPresent information
   (see section 5.3).

   muxConfigPresent: If this value is set to 1 (in-band mode), the
   audioMuxElement SHALL include an indication bit "useSameStreamMux"
   and MAY include the configuration information for audio compression
   "StreamMuxConfig".  The useSameStreamMux bit indicates whether the
   StreamMuxConfig element in the previous frame is applied in the
   current frame.  If the useSameStreamMux bit indicates to use the
   StreamMuxConfig from the previous frame, but if the previous frame
   has been lost, the current frame may not be decodable.  Therefore, in
   case of in-band mode, the StreamMuxConfig element SHOULD be
   transmitted repeatedly depending on the network condition.  On the
   other hand, if muxConfigPresent is set to 0 (out-band mode), the
   StreamMuxConfig element is required to be transmitted by an out-of-
   band means.  In case of SDP, MIME parameter "config" is utilized (see
   section 5.3).

4.2 Use of RTP Header Fields for MPEG-4 Audio

   Payload Type (PT): The assignment of an RTP payload type for this new
   packet format is outside the scope of this document, and will not be
   specified here.  It is expected that the RTP profile for a particular
   class of applications will assign a payload type for this encoding,



Kikuchi, et al.             Standards Track                    [Page 11]

RFC 3016       RTP Payload Format for MPEG-4 Audio/Visual  November 2000


   or if that is not done then a payload type in the dynamic range shall
   be chosen by means of an out of band signaling protocol (e.g., H.245,
   SIP, etc).  In the dynamic assignment of RTP payload types for
   scalable streams, a different value SHOULD be assigned to each layer.
   The assigned values SHOULD be in order of enhance layer dependency,
   where the base layer has the smallest value.

   Marker (M) bit: The marker bit indicates audioMuxElement boundaries.
   It is set to one to indicate that the RTP packet contains a complete
   audioMuxElement or the last fragment of an audioMuxElement.

   Timestamp: The timestamp indicates the sampling instance of the first
   audio frame contained in the RTP packet.  Timestamps are recommended
   to start at a random value for security reasons.

   Unless specified by an out-of-band means, the resolution of the
   timestamp is set to its default value of 90 kHz.

   Sequence Number: Incremented by one for each RTP packet sent,
   starting, for security reasons, with a random value.

   Other header fields are used as described in RFC 1889 [8].

4.3 Fragmentation of MPEG-4 Audio bitstream

   It is RECOMMENDED to put one audioMuxElement in each RTP packet.  If
   the size of an audioMuxElement can be kept small enough that the size
   of the RTP packet containing it does not exceed the size of the
   path-MTU, this will be no problem.  If it cannot, the audioMuxElement
   MAY be fragmented and spread across multiple packets.

5. MIME type registration for MPEG-4 Audio/Visual streams

   The following sections describe the MIME type registrations for
   MPEG-4 Audio/Visual streams.  MIME type registration and SDP usage
   for the MPEG-4 Visual stream are described in Sections 5.1 and 5.2,
   respectively, while MIME type registration and SDP usage for MPEG-4
   Audio stream are described in Sections 5.3 and 5.4, respectively.

5.1 MIME type registration for MPEG-4 Visual

   MIME media type name: video

   MIME subtype name: MP4V-ES

   Required parameters: none

   Optional parameters:



Kikuchi, et al.             Standards Track                    [Page 12]

RFC 3016       RTP Payload Format for MPEG-4 Audio/Visual  November 2000


      rate: This parameter is used only for RTP transport.  It indicates
      the resolution of the timestamp field in the RTP header.  If this
      parameter is not specified, its default value of 90000 (90kHz) is
      used.

      profile-level-id: A decimal representation of MPEG-4 Visual
      Profile and Level indication value (profile_and_level_indication)
      defined in Table G-1 of ISO/IEC 14496-2 [2][4].  This parameter
      MAY be used in the capability exchange or session setup procedure
      to indicate MPEG-4 Visual Profile and Level combination of which
      the MPEG-4 Visual codec is capable.  If this parameter is not
      specified by the procedure, its default value of 1 (Simple
      Profile/Level 1) is used.

      config: This parameter SHALL be used to indicate the configuration
      of the corresponding MPEG-4 Visual bitstream.  It SHALL NOT be
      used to indicate the codec capability in the capability exchange
      procedure.  It is a hexadecimal representation of an octet string
      that expresses the MPEG-4 Visual configuration information, as
      defined in subclause 6.2.1 Start codes of ISO/IEC14496-2
      [2][4][9].  The configuration information is mapped onto the octet
      string in an MSB-first basis.  The first bit of the configuration
      information SHALL be located at the MSB of the first octet.  The
      configuration information indicated by this parameter SHALL be the
      same as the configuration information in the corresponding MPEG-4
      Visual stream, except for first_half_vbv_occupancy and
      latter_half_vbv_occupancy, if exist, which may vary in the
      repeated configuration information inside an MPEG-4 Visual stream
      (See 6.2.1 Start codes of ISO/IEC14496-2).

      Example usages for these parameters are:

        -  MPEG-4 Visual Simple Profile/Level 1:
            Content-type: video/mp4v-es; profile-level-id=1

        -  MPEG-4 Visual Core Profile/Level 2:
            Content-type: video/mp4v-es; profile-level-id=34

        -  MPEG-4 Visual Advanced Real Time Simple Profile/Level 1:
            Content-type: video/mp4v-es; profile-level-id=145

   Published specification:
      The specifications for MPEG-4 Visual streams are presented in
      ISO/IEC 14469-2 [2][4][9].  The RTP payload format is described in
      RFC 3016.






Kikuchi, et al.             Standards Track                    [Page 13]

RFC 3016       RTP Payload Format for MPEG-4 Audio/Visual  November 2000


   Encoding considerations:
      Video bitstreams MUST be generated according to MPEG-4 Visual
      specifications (ISO/IEC 14496-2).  A video bitstream is binary
      data and MUST be encoded for non-binary transport (for Email, the
      Base64 encoding is sufficient).  This type is also defined for
      transfer via RTP.  The RTP packets MUST be packetized according to
      the MPEG-4 Visual RTP payload format defined in RFC 3016.

   Security considerations:
      See section 6 of RFC 3016.

   Interoperability considerations:
      MPEG-4 Visual provides a large and rich set of tools for the
      coding of visual objects.  For effective implementation of the
      standard, subsets of the MPEG-4 Visual tool sets have been
      provided for use in specific applications.  These subsets, called
      'Profiles', limit the size of the tool set a decoder is required
      to implement.  In order to restrict computational complexity, one
      or more Levels are set for each Profile.  A Profile@Level
      combination allows:

      o a codec builder to implement only the subset of the standard he
      needs, while maintaining interworking with other MPEG-4 devices
      included in the same combination, and

      o checking whether MPEG-4 devices comply with the standard ('
      conformance testing').

      The visual stream SHALL be compliant with the MPEG-4 Visual
      Profile@Level specified by the parameter "profile-level-id".
      Interoperability between a sender and a receiver may be achieved
      by specifying the parameter "profile-level-id" in MIME content, or
      by arranging in the capability exchange/announcement procedure to
      set this parameter mutually to the same value.

   Applications which use this media type:
      Audio and visual streaming and conferencing tools, Internet
      messaging and Email applications.

   Additional information: none

   Person & email address to contact for further information:
      The authors of RFC 3016.  (See section 8.)

   Intended usage: COMMON

   Author/Change controller:
      The authors of RFC 3016.  (See section 8.)



Kikuchi, et al.             Standards Track                    [Page 14]

RFC 3016       RTP Payload Format for MPEG-4 Audio/Visual  November 2000


5.2 SDP usage of MPEG-4 Visual

   The MIME media type video/MP4V-ES string is mapped to fields in the
   Session Description Protocol (SDP), RFC 2327, as follows:

   o  The MIME type (video) goes in SDP "m=" as the media name.

   o  The MIME subtype (MP4V-ES) goes in SDP "a=rtpmap" as the encoding
      name.

   o  The optional parameter "rate" goes in "a=rtpmap" as the clock
      rate.

   o  The optional parameter "profile-level-id" and "config" go in the
      "a=fmtp" line to indicate the coder capability and configuration,
      respectively.  These parameters are expressed as a MIME media type
      string, in the form of as a semicolon separated list of
      parameter=value pairs.

   The following are some examples of media representation in SDP:

Simple Profile/Level 1, rate=90000(90kHz), "profile-level-id" and
"config" are present in "a=fmtp" line:
  m=video 49170/2 RTP/AVP 98
  a=rtpmap:98 MP4V-ES/90000
  a=fmtp:98 profile-level-id=1;config=000001B001000001B509000001000000012
     0008440FA282C2090A21F

Core Profile/Level 2, rate=90000(90kHz), "profile-level-id" is present in
"a=fmtp" line:
  m=video 49170/2 RTP/AVP 98
  a=rtpmap:98 MP4V-ES/90000
  a=fmtp:98 profile-level-id=34

Advance Real Time Simple Profile/Level 1, rate=90000(90kHz),
"profile-level-id" is present in "a=fmtp" line:
  m=video 49170/2 RTP/AVP 98
  a=rtpmap:98 MP4V-ES/90000
  a=fmtp:98 profile-level-id=145

5.3 MIME type registration of MPEG-4 Audio

   MIME media type name: audio

   MIME subtype name: MP4A-LATM






Kikuchi, et al.             Standards Track                    [Page 15]

RFC 3016       RTP Payload Format for MPEG-4 Audio/Visual  November 2000


   Required parameters:
      rate: the rate parameter indicates the RTP time stamp clock rate.
      The default value is 90000.  Other rates MAY be specified only if
      they are set to the same value as the audio sampling rate (number
      of samples per second).

   Optional parameters:
      profile-level-id: a decimal representation of MPEG-4 Audio Profile
      Level indication value defined in ISO/IEC 14496-1 ([6] and its
      amendments).  This parameter indicates which MPEG-4 Audio tool
      subsets the decoder is capable of using.  If this parameter is not
      specified in the capability exchange or session setup procedure,
      its default value of 30 (Natural Audio Profile/Level 1) is used.

      object: a decimal representation of the MPEG-4 Audio Object Type
      value defined in ISO/IEC 14496-3 [5].  This parameter specifies
      the tool to be used by the coder.  It CAN be used to limit the
      capability within the specified "profile-level-id".

      bitrate: the data rate for the audio bit stream.

      cpresent: a boolean parameter indicates whether audio payload
      configuration data has been multiplexed into an RTP payload (see
      section 4.1).  A 0 indicates the configuration data has not been
      multiplexed into an RTP payload, a 1 indicates that it has.  The
      default if the parameter is omitted is 1.

      config: a hexadecimal representation of an octet string that
      expresses the audio payload configuration data "StreamMuxConfig",
      as defined in ISO/IEC 14496-3 [5] (see section 4.1).
      Configuration data is mapped onto the octet string in an MSB-first
      basis.  The first bit of the configuration data SHALL be located
      at the MSB of the first octet.  In the last octet, zero-padding
      bits, if necessary, SHALL follow the configuration data.

      ptime: RECOMMENDED duration of each packet in milliseconds.

   Published specification:
      Payload format specifications are described in this document.