rfc1890.txt

网络MPEG4IP流媒体开发源代码

5.4 MPV

   MPV designates the use MPEG-I and MPEG-II video encoding elementary
   streams as specified in ISO Standards ISO/IEC 11172 and 13818-2,
   respectively. The RTP payload format is as specified in work in
   progress [10], Section 3. See the description of the MPA audio
   encoding for contact information.

5.5 MP2T

   MP2T designates the use of MPEG-II transport streams, for either
   audio or video. The encapsulation is described in work in progress,
   [10], Section 2. See the description of the MPA audio encoding for
   contact information.

5.6 nv

   The encoding is implemented in the program 'nv', version 4, developed
   at Xerox PARC by Ron Frederick. Further information is available from
   the author:

   Ron Frederick
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304
   United States
   electronic mail: [e-mail]

6.  Payload Type Definitions

   Table 2 defines this profile's static payload type values for the PT
   field of the RTP data header. A new RTP payload format specification
   may be registered with the IANA by name, and may also be assigned a
   static payload type value from the range marked in Section 3.

   In addition, payload type values in the range 96-127 may be defined
   dynamically through a conference control protocol, which is beyond
   the scope of this document. For example, a session directory could
   specify that for a given session, payload type 96 indicates PCMU
   encoding, 8,000 Hz sampling rate, 2 channels. The payload type range
   marked 'reserved' has been set aside so that RTCP and RTP packets can
   be reliably distinguished (see Section "Summary of Protocol
   Constants" of the RTP protocol specification).

   An RTP source emits a single RTP payload type at any given time; the
   interleaving of several RTP payload types in a single RTP session is
   not allowed, but multiple RTP sessions may be used in parallel to
   send multiple media. The payload types currently defined in this



Schulzrinne                 Standards Track                    [Page 13]

RFC 1890                       AV Profile                   January 1996


   profile carry either audio or video, but not both. However, it is
   allowed to define payload types that combine several media, e.g.,
   audio and video, with appropriate separation in the payload format.
   Session participants agree through mechanisms beyond the scope of
   this specification on the set of payload types allowed in a given
   session.  This set may, for example, be defined by the capabilities
   of the applications used, negotiated by a conference control protocol
   or established by agreement between the human participants.

   Audio applications operating under this profile should, at minimum,
   be able to send and receive payload types 0  (PCMU)  and 5 (DVI4).
   This allows interoperability without format negotiation and
   successful negotation with a conference control protocol.

   All current video encodings use a timestamp frequency of 90,000 Hz,
   the same as the MPEG presentation time stamp frequency. This
   frequency yields exact integer timestamp increments for the typical
   24 (HDTV), 25 (PAL), and 29.97 (NTSC) and 30 Hz (HDTV) frame rates
   and 50, 59.94 and 60 Hz field rates. While 90 kHz is the recommended
   rate for future video encodings used within this profile, other rates
   are possible. However, it is not sufficient to use the video frame
   rate (typically between 15 and 30 Hz) because that does not provide
   adequate resolution for typical synchronization requirements when
   calculating the RTP timestamp corresponding to the NTP timestamp in
   an RTCP SR packet [15]. The timestamp resolution must also be
   sufficient for the jitter estimate contained in the receiver reports.

   The standard video encodings and their payload types are listed in
   Table 2.

7.  Port Assignment

   As specified in the RTP protocol definition, RTP data is to be
   carried on an even UDP port number and the corresponding RTCP packets
   are to be carried on the next higher (odd) port number.

   Applications operating under this profile may use any such UDP port
   pair. For example, the port pair may be allocated randomly by a
   session management program. A single fixed port number pair cannot be
   required because multiple applications using this profile are likely
   to run on the same host, and there are some operating systems that do
   not allow multiple processes to use the same UDP port with different
   multicast addresses.








Schulzrinne                 Standards Track                    [Page 14]

RFC 1890                       AV Profile                   January 1996


      PT         encoding      audio/video    clock rate    channels
                 name          (A/V)          (Hz)          (audio)
      _______________________________________________________________
      0          PCMU          A              8000          1
      1          1016          A              8000          1
      2          G721          A              8000          1
      3          GSM           A              8000          1
      4          unassigned    A              8000          1
      5          DVI4          A              8000          1
      6          DVI4          A              16000         1
      7          LPC           A              8000          1
      8          PCMA          A              8000          1
      9          G722          A              8000          1
      10         L16           A              44100         2
      11         L16           A              44100         1
      12         unassigned    A
      13         unassigned    A
      14         MPA           A              90000        (see text)
      15         G728          A              8000          1
      16--23     unassigned    A
      24         unassigned    V
      25         CelB          V              90000
      26         JPEG          V              90000
      27         unassigned    V
      28         nv            V              90000
      29         unassigned    V
      30         unassigned    V
      31         H261          V              90000
      32         MPV           V              90000
      33         MP2T          AV             90000
      34--71     unassigned    ?
      72--76     reserved      N/A            N/A           N/A
      77--95     unassigned    ?
      96--127    dynamic       ?

   Table 2: Payload types (PT) for standard audio and video encodings

   However, port numbers 5004 and 5005 have been registered for use with
   this profile for those applications that choose to use them as the
   default pair. Applications that operate under multiple profiles may
   use this port pair as an indication to select this profile if they
   are not subject to the constraint of the previous paragraph.
   Applications need not have a default and may require that the port
   pair be explicitly specified. The particular port numbers were chosen
   to lie in the range above 5000 to accomodate port number allocation
   practice within the Unix operating system, where port numbers below
   1024 can only be used by privileged processes and port numbers
   between 1024 and 5000 are automatically assigned by the operating



Schulzrinne                 Standards Track                    [Page 15]

RFC 1890                       AV Profile                   January 1996


   system.

8. Bibliography

   [1] Apple Computer, "Audio interchange file format AIFF-C," Aug.
       1991.  (also ftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z).

   [2] Office of Technology and Standards, "Telecommunications: Analog
       to digital conversion of radio voice by 4,800 bit/second code
       excited linear prediction (celp)," Federal Standard FS-1016, GSA,
       Room 6654; 7th & D Street SW; Washington, DC 20407 (+1-202-708-
       9205), 1990.

   [3] J. P. Campbell, Jr., T. E. Tremain, and V. C. Welch, "The
       proposed Federal Standard 1016 4800 bps voice coder: CELP,"
       Speech Technology , vol. 5, pp. 58--64, April/May 1990.

   [4] J. P. Campbell, Jr., T. E. Tremain, and V. C. Welch, "The federal
       standard 1016 4800 bps CELP voice coder," Digital Signal
       Processing, vol. 1, no. 3, pp. 145--155, 1991.

   [5] J. P. Campbell, Jr., T. E. Tremain, and V. C. Welch, "The dod 4.8
       kbps standard (proposed federal standard 1016)," in Advances in
       Speech Coding (B. Atal, V. Cuperman, and A. Gersho, eds.), ch.
       12, pp. 121--133, Kluwer Academic Publishers, 1991.

   [6] IMA Digital Audio Focus and Technical Working Groups,
       "Recommended practices for enhancing digital audio compatibility
       in multimedia systems (version 3.00)," tech. rep., Interactive
       Multimedia Association, Annapolis, Maryland, Oct. 1992.

   [7] M. Mouly and M.-B. Pautet, The GSM system for mobile
       communications Lassay-les-Chateaux, France: Europe Media
       Duplication, 1993.

   [8] J. Degener, "Digital speech compression," Dr. Dobb's Journal,
       Dec.  1994.

   [9] S. M. Redl, M. K. Weber, and M. W. Oliphant, An Introduction to
       GSM Boston: Artech House, 1995.

  [10] D. Hoffman and V. Goyal, "RTP payload format for MPEG1/MPEG2
       video," Work in Progress, Internet Engineering Task Force, June
       1995.

  [11] N. S. Jayant and P. Noll, Digital Coding of Waveforms--
       Principles and Applications to Speech and Video Englewood Cliffs,
       New Jersey: Prentice-Hall, 1984.



Schulzrinne                 Standards Track                    [Page 16]

RFC 1890                       AV Profile                   January 1996


  [12] M. F. Speer and D. Hoffman, "RTP payload format of CellB video
       encoding," Work in Progress, Internet Engineering Task Force,
       Aug.  1995.

  [13] W. Fenner, L. Berc, R. Frederick, and S. McCanne, "RTP
       encapsulation of JPEG-compressed video," Work in Progress,
       Internet Engineering Task Force, Mar. 1995.

  [14] T. Turletti and C. Huitema, "RTP payload format for H.261 video
       streams," Work in Progress, Internet Engineering Task Force, July
       1995.

  [15] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
       transport protocol for real-time applications." Work in Progress,
       Mar. 1995.

9.  Security Considerations

   Security issues are discussed in section 2.

10.  Acknowledgements

   The comments and careful review of Steve Casner are gratefully
   acknowledged.

11.  Author's Address

   Henning Schulzrinne
   GMD Fokus
   Hardenbergplatz 2
   D-10623 Berlin
   Germany

   EMail: [e-mail]

















Schulzrinne                 Standards Track                    [Page 17]

RFC 1890                       AV Profile                   January 1996


   Current Locations of Related Resources


   UTF-8

   Information on the UCS Transformation Format 8 (UTF-8) is available
   at

            http://www.stonehand.com/unicode/standard/utf8.html


   1016

   An implementation is available at

              ftp://ftp.super.org/pub/speech/celp_3.2a.tar.Z

   DVI4

   An implementation is available from Jack Jansen at

                ftp://ftp.cwi.nl/local/pub/audio/adpcm.shar


   G721

   An implementation is available at

       ftp://gaia.cs.umass.edu/pub/hgschulz/ccitt/ccitt_tools.tar.Z


   GSM

   A reference implementation was written by Carsten Borman and Jutta
   Degener (TU Berlin, Germany). It is available at

            ftp://ftp.cs.tu-berlin.de/pub/local/kbs/tubmik/gsm/


   LPC

   An implementation is available at

            ftp://parcftp.xerox.com/pub/net-research/lpc.tar.Z







Schulzrinne                 Standards Track                    [Page 18]