rfc3551.txt

完整的RTP RTSP代码库

   frame size which is defined as part of the encoding.  This does not
   work when carrying frames of different sizes unless the frame sizes
   are relatively prime.  If not, the frames MUST indicate their size.

   For frame-based codecs, the channel order is defined for the whole
   block.  That is, for two-channel audio, right and left samples SHOULD
   be coded independently, with the encoded frame for the left channel
   preceding that for the right channel.

   All frame-oriented audio codecs SHOULD be able to encode and decode
   several consecutive frames within a single packet.  Since the frame
   size for the frame-oriented codecs is given, there is no need to use
   a separate designation for the same encoding, but with different
   number of frames per packet.

   RTP packets SHALL contain a whole number of frames, with frames
   inserted according to age within a packet, so that the oldest frame
   (to be played first) occurs immediately after the RTP packet header.
   The RTP timestamp reflects the instant at which the first sample in
   the first frame was sampled, that is, the oldest information in the
   packet.






















Schulzrinne & Casner        Standards Track                    [Page 11]

RFC 3551                    RTP A/V Profile                    July 2003


4.5 Audio Encodings

   name of                              sampling              default
   encoding  sample/frame  bits/sample      rate  ms/frame  ms/packet
   __________________________________________________________________
   DVI4      sample        4                var.                   20
   G722      sample        8              16,000                   20
   G723      frame         N/A             8,000        30         30
   G726-40   sample        5               8,000                   20
   G726-32   sample        4               8,000                   20
   G726-24   sample        3               8,000                   20
   G726-16   sample        2               8,000                   20
   G728      frame         N/A             8,000       2.5         20
   G729      frame         N/A             8,000        10         20
   G729D     frame         N/A             8,000        10         20
   G729E     frame         N/A             8,000        10         20
   GSM       frame         N/A             8,000        20         20
   GSM-EFR   frame         N/A             8,000        20         20
   L8        sample        8                var.                   20
   L16       sample        16               var.                   20
   LPC       frame         N/A             8,000        20         20
   MPA       frame         N/A              var.      var.
   PCMA      sample        8                var.                   20
   PCMU      sample        8                var.                   20
   QCELP     frame         N/A             8,000        20         20
   VDVI      sample        var.             var.                   20

   Table 1: Properties of Audio Encodings (N/A: not applicable; var.:
            variable)

   The characteristics of the audio encodings described in this document
   are shown in Table 1; they are listed in order of their payload type
   in Table 4.  While most audio codecs are only specified for a fixed
   sampling rate, some sample-based algorithms (indicated by an entry of
   "var." in the sampling rate column of Table 1) may be used with
   different sampling rates, resulting in different coded bit rates.
   When used with a sampling rate other than that for which a static
   payload type is defined, non-RTP means beyond the scope of this memo
   MUST be used to define a dynamic payload type and MUST indicate the
   selected RTP timestamp clock rate, which is usually the same as the
   sampling rate for audio.










Schulzrinne & Casner        Standards Track                    [Page 12]

RFC 3551                    RTP A/V Profile                    July 2003


4.5.1 DVI4

   DVI4 uses an adaptive delta pulse code modulation (ADPCM) encoding
   scheme that was specified by the Interactive Multimedia Association
   (IMA) as the "IMA ADPCM wave type".  However, the encoding defined
   here as DVI4 differs in three respects from the IMA specification:

   o  The RTP DVI4 header contains the predicted value rather than the
      first sample value contained the IMA ADPCM block header.

   o  IMA ADPCM blocks contain an odd number of samples, since the first
      sample of a block is contained just in the header (uncompressed),
      followed by an even number of compressed samples.  DVI4 has an
      even number of compressed samples only, using the `predict' word
      from the header to decode the first sample.

   o  For DVI4, the 4-bit samples are packed with the first sample in
      the four most significant bits and the second sample in the four
      least significant bits.  In the IMA ADPCM codec, the samples are
      packed in the opposite order.

   Each packet contains a single DVI block.  This profile only defines
   the 4-bit-per-sample version, while IMA also specified a 3-bit-per-
   sample encoding.

   The "header" word for each channel has the following structure:

      int16  predict;  /* predicted value of first sample
                          from the previous block (L16 format) */
      u_int8 index;    /* current index into stepsize table */
      u_int8 reserved; /* set to zero by sender, ignored by receiver */

   Each octet following the header contains two 4-bit samples, thus the
   number of samples per packet MUST be even because there is no means
   to indicate a partially filled last octet.

   Packing of samples for multiple channels is for further study.

   The IMA ADPCM algorithm was described in the document IMA Recommended
   Practices for Enhancing Digital Audio Compatibility in Multimedia
   Systems (version 3.0).  However, the Interactive Multimedia
   Association ceased operations in 1997.  Resources for an archived
   copy of that document and a software implementation of the RTP DVI4
   encoding are listed in Section 13.







Schulzrinne & Casner        Standards Track                    [Page 13]

RFC 3551                    RTP A/V Profile                    July 2003


4.5.2 G722

   G722 is specified in ITU-T Recommendation G.722, "7 kHz audio-coding
   within 64 kbit/s".  The G.722 encoder produces a stream of octets,
   each of which SHALL be octet-aligned in an RTP packet.  The first bit
   transmitted in the G.722 octet, which is the most significant bit of
   the higher sub-band sample, SHALL correspond to the most significant
   bit of the octet in the RTP packet.

   Even though the actual sampling rate for G.722 audio is 16,000 Hz,
   the RTP clock rate for the G722 payload format is 8,000 Hz because
   that value was erroneously assigned in RFC 1890 and must remain
   unchanged for backward compatibility.  The octet rate or sample-pair
   rate is 8,000 Hz.

4.5.3 G723

   G723 is specified in ITU Recommendation G.723.1, "Dual-rate speech
   coder for multimedia communications transmitting at 5.3 and 6.3
   kbit/s".  The G.723.1 5.3/6.3 kbit/s codec was defined by the ITU-T
   as a mandatory codec for ITU-T H.324 GSTN videophone terminal
   applications.  The algorithm has a floating point specification in
   Annex B to G.723.1, a silence compression algorithm in Annex A to
   G.723.1 and a scalable channel coding scheme for wireless
   applications in G.723.1 Annex C.

   This Recommendation specifies a coded representation that can be used
   for compressing the speech signal component of multi-media services
   at a very low bit rate.  Audio is encoded in 30 ms frames, with an
   additional delay of 7.5 ms due to look-ahead.  A G.723.1 frame can be
   one of three sizes:  24 octets (6.3 kb/s frame), 20 octets (5.3 kb/s
   frame), or 4 octets.  These 4-octet frames are called SID frames
   (Silence Insertion Descriptor) and are used to specify comfort noise
   parameters.  There is no restriction on how 4, 20, and 24 octet
   frames are intermixed.  The least significant two bits of the first
   octet in the frame determine the frame size and codec type:

         bits  content                      octets/frame
         00    high-rate speech (6.3 kb/s)            24
         01    low-rate speech  (5.3 kb/s)            20
         10    SID frame                               4
         11    reserved









Schulzrinne & Casner        Standards Track                    [Page 14]

RFC 3551                    RTP A/V Profile                    July 2003


   It is possible to switch between the two rates at any 30 ms frame
   boundary.  Both (5.3 kb/s and 6.3 kb/s) rates are a mandatory part of
   the encoder and decoder.  Receivers MUST accept both data rates and
   MUST accept SID frames unless restriction of these capabilities has
   been signaled.  The MIME registration for G723 in RFC 3555 [7]
   specifies parameters that MAY be used with MIME or SDP to restrict to
   a single data rate or to restrict the use of SID frames.  This coder
   was optimized to represent speech with near-toll quality at the above
   rates using a limited amount of complexity.

   The packing of the encoded bit stream into octets and the
   transmission order of the octets is specified in Rec. G.723.1 and is
   the same as that produced by the G.723 C code reference
   implementation.  For the 6.3 kb/s data rate, this packing is
   illustrated as follows, where the header (HDR) bits are always "0 0"
   as shown in Fig. 1 to indicate operation at 6.3 kb/s, and the Z bit
   is always set to zero.  The diagrams show the bit packing in "network
   byte order", also known as big-endian order.  The bits of each 32-bit
   word are numbered 0 to 31, with the most significant bit on the left
   and numbered 0.  The octets (bytes) of each word are transmitted most
   significant octet first.  The bits of each data field are numbered in
   the order of the bit stream representation of the encoding (least
   significant bit first).  The vertical bars indicate the boundaries
   between field fragments.



























Schulzrinne & Casner        Standards Track                    [Page 15]

RFC 3551                    RTP A/V Profile                    July 2003


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    LPC    |HDR|      LPC      |      LPC      |    ACL0   |LPC|
   |           |   |               |               |           |   |
   |0 0 0 0 0 0|0 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2|
   |5 4 3 2 1 0|   |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ACL2   |ACL|A| GAIN0 |ACL|ACL|    GAIN0      |    GAIN1      |
   |         | 1 |C|       | 3 | 2 |               |               |
   |0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
   |4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | GAIN2 | GAIN1 |     GAIN2     |     GAIN3     | GRID  | GAIN3 |
   |       |       |               |               |       |       |