rfc3016.txt

最新的RFC

      Encoding specifications are provided in ISO/IEC 14496-3 [3][5].

   Encoding considerations:
      This type is only defined for transfer via RTP.

   Security considerations:
      See Section 6 of RFC 3016.





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


   Interoperability considerations:
      MPEG-4 Audio provides a large and rich set of tools for the coding
      of audio objects.  For effective implementation of the standard,
      subsets of the MPEG-4 Audio tool sets similar to those used in
      MPEG-4 Visual have been provided (see section 5.1).

      The audio stream SHALL be compliant with the MPEG-4 Audio
      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 procedure to set this
      parameter mutually to the same value.  Furthermore, the "object"
      parameter can be used to limit the capability within the specified
      Profile@Level in capability exchange.

   Applications which use this media type:
      Audio and video streaming and conferencing tools.

   Additional information: none

   Personal & email address to contact for further information:
      See Section 8 of RFC 3016.

   Intended usage: COMMON

   Author/Change controller:
      See Section 8 of RFC 3016.

5.4 SDP usage of MPEG-4 Audio

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

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

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

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

   o  The optional parameter "ptime" goes in SDP "a=ptime" attribute.

   o  The optional parameter "profile-level-id" goes in the "a=fmtp"
      line to indicate the coder capability.  The "object" parameter
      goes in the "a=fmtp" attribute.  The payload-format-specific
      parameters




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


      "bitrate", "cpresent" and "config" go in the "a=fmtp" line.  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 the media representation in SDP:

For 6 kb/s CELP bitstreams (with an audio sampling rate of 8 kHz),
  m=audio 49230 RTP/AVP 96
  a=rtpmap:96 MP4A-LATM/8000
  a=fmtp:96 profile-level-id=9;object=8;cpresent=0;config=9128B1071070
  a=ptime:20

   For 64 kb/s AAC LC stereo bitstreams (with an audio sampling rate of
   24 kHz),

      m=audio 49230 RTP/AVP 96
      a=rtpmap:96 MP4A-LATM/24000
      a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0;
      config=9122620000

   In the above two examples, audio configuration data is not
   multiplexed into the RTP payload and is described only in SDP.
   Furthermore, the "clock rate" is set to the audio sampling rate.

   If the clock rate has been set to its default value and it is
   necessary to obtain the audio sampling rate, this can be done by
   parsing the "config" parameter (see the following example).

      m=audio 49230 RTP/AVP 96
      a=rtpmap:96 MP4A-LATM/90000
      a=fmtp:96 object=8; cpresent=0; config=9128B1071070

   The following example shows that the audio configuration data appears
   in the RTP payload.

      m=audio 49230 RTP/AVP 96
      a=rtpmap:96 MP4A-LATM/90000
      a=fmtp:96 object=2; cpresent=1

6. Security Considerations

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [8].  This implies that confidentiality of the media
   streams is achieved by encryption.  Because the data compression used
   with this payload format is applied end-to-end, encryption may be
   performed on the compressed data so there is no conflict between the
   two operations.



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


   The complete MPEG-4 system allows for transport of a wide range of
   content, including Java applets (MPEG-J) and scripts.  Since this
   payload format is restricted to audio and video streams, it is not
   possible to transport such active content in this format.

7. References

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  ISO/IEC 14496-2:1999, "Information technology - Coding of audio-
      visual objects - Part2: Visual".

   3  ISO/IEC 14496-3:1999, "Information technology - Coding of audio-
      visual objects - Part3: Audio".

   4  ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology - Coding
      of audio-visual objects - Part 2: Visual, Amendment 1: Visual
      extensions".

   5  ISO/IEC 14496-3:1999/Amd.1:2000, "Information technology - Coding
      of audio-visual objects - Part3: Audio, Amendment 1: Audio
      extensions".

   6  ISO/IEC 14496-1:1999, "Information technology - Coding of audio-
      visual objects - Part1: Systems".

   7  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

   8  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson "RTP: A
      Transport Protocol for Real Time Applications", RFC 1889, January
      1996.

   9  ISO/IEC 14496-2:1999/Cor.1:2000, "Information technology - Coding
      of audio-visual objects - Part2: Visual, Technical corrigendum 1".















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


8. Authors' Addresses

   Yoshihiro Kikuchi
   Toshiba corporation
   1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki, 212-8582, Japan

   EMail: [e-mail]


   Yoshinori Matsui
   Matsushita Electric Industrial Co., LTD.
   1006, Kadoma, Kadoma-shi, Osaka, Japan

   EMail: [e-mail]


   Toshiyuki Nomura
   NEC Corporation
   4-1-1,Miyazaki,Miyamae-ku,Kawasaki,JAPAN

   EMail: [e-mail]


   Shigeru Fukunaga
   Oki Electric Industry Co., Ltd.
   1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan.

   EMail: [e-mail]


   Hideaki Kimata
   Nippon Telegraph and Telephone Corporation
   1-1, Hikari-no-oka, Yokosuka-shi, Kanagawa, Japan

   EMail: [e-mail]
















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


9. Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Kikuchi, et al.             Standards Track                    [Page 21]