rfc3119.txt

RFC 的详细文档！

Network Working Group                                       R. Finlayson
Request for Comments: 3119                                      LIVE.COM
Category: Standards Track                                      June 2001


         A More Loss-Tolerant RTP Payload Format for MP3 Audio

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document describes a RTP (Real-Time Protocol) payload format for
   transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III
   audio (commonly known as "MP3").  This format is an alternative to
   that described in RFC 2250, and performs better if there is packet
   loss.

1. Introduction

   While the RTP payload format defined in RFC 2250 [2] is generally
   applicable to all forms of MPEG audio or video, it is sub-optimal for
   MPEG 1 or 2, layer III audio (commonly known as "MP3").  The reason
   for this is that an MP3 frame is not a true "Application Data Unit" -
   it contains a back-pointer to data in earlier frames, and so cannot
   be decoded independently of these earlier frames.  Because RFC 2250
   defines that packet boundaries coincide with frame boundaries, it
   handles packet loss inefficiently when carrying MP3 data.  The loss
   of an MP3 frame will render some data in previous (or future) frames
   useless, even if they are received without loss.

   In this document we define an alternative RTP payload format for MP3
   audio.  This format uses a data-preserving rearrangement of the
   original MPEG frames, so that packet boundaries now coincide with
   true MP3 "Application Data Units", which can also (optionally) be
   rearranged in an interleaving pattern.  This new format is therefore
   more data-efficient than RFC 2250 in the face of packet loss.





Finlayson                   Standards Track                     [Page 1]

RFC 3119     Loss-Tolerant RTP Payload Format for MP3 Audio    June 2001


2. The Structure of MP3 Frames

   In this section we give a brief overview of the structure of a MP3
   frame.  (For more detailed description, see the MPEG 1 audio [3] and
   MPEG 2 audio [4] specifications.)

   Each MPEG audio frame begins with a 4-byte header.  Information
   defined by this header includes:

   -  Whether the audio is MPEG 1 or MPEG 2.
   -  Whether the audio is layer I, II, or III.
      (The remainder of this document assumes layer III, i.e., "MP3"
      frames)
   -  Whether the audio is mono or stereo.
   -  Whether or not there is a 2-byte CRC field following the header.
   -  (indirectly) The size of the frame.

   The following structures appear after the header:

   -  (optionally) A 2-byte CRC field
   -  A "side info" structure.  This has the following length:
      -  32 bytes for MPEG 1 stereo
      -  17 bytes for MPEG 1 mono, or for MPEG 2 stereo
      -  9 bytes for MPEG 2 mono
   -  Encoded audio data, plus optional ancillary data (filling out the
      rest of the frame)

   For the purpose of this document, the "side info" structure is the
   most important, because it defines the location and size of the
   "Application Data Unit" (ADU) that an MP3 decoder will process.  In
   particular, the "side info" structure defines:

   -  "main_data_begin": This is a back-pointer (in bytes) to the start
      of the ADU.  The back-pointer is counted from the beginning of the
      frame, and counts only encoded audio data and any ancillary data
      (i.e., ignoring any header, CRC, or "side info" fields).

   An MP3 decoder processes each ADU independently.  The ADUs will
   generally vary in length, but their average length will, of course,
   be that of the of the MP3 frames (minus the length of the header,
   CRC, and "side info" fields).  (In MPEG literature, this ADU is
   sometimes referred to as a "bit reservoir".)









Finlayson                   Standards Track                     [Page 2]

RFC 3119     Loss-Tolerant RTP Payload Format for MP3 Audio    June 2001


3. A New Payload Format

   As noted in [5], a payload format should be designed so that packet
   boundaries coincide with "codec frame boundaries" - i.e., with ADUs.
   In the RFC 2250 payload format for MPEG audio [2], each RTP packet
   payload contains MP3 frames.  In this new payload format for MP3
   audio, however, each RTP packet payload contains "ADU frames", each
   preceded by an "ADU descriptor".

3.1 ADU frames

   An "ADU frame" is defined as:

      -  The 4-byte MPEG header
         (the same as the original MP3 frame, except that the first 11
         bits are (optionally) replaced by an "Interleaving Sequence
         Number", as described in section 6 below)
      -  The optional 2-byte CRC field
         (the same as the original MP3 frame)
      -  The "side info" structure
         (the same as the original MP3 frame)
      -  The complete sequence of encoded audio data (and any ancillary
         data) for the ADU (i.e., running from the start of this MP3
         frame's "main_data_begin" back-pointer, up to the start of the
         next MP3 frame's back-pointer)

3.2 ADU descriptors

   Within each RTP packet payload, each "ADU frame" is preceded by a 1
   or 2-byte "ADU descriptor", which gives the size of the ADU, and
   indicates whether or not this packet's data is a continuation of the
   previous packet's data.  (This occurs only when a single "ADU
   descriptor"+"ADU frame" is too large to fit within a RTP packet.)

   An ADU descriptor consists of the following fields

   -  "C": Continuation flag (1 bit):  1 if the data following the ADU
           descriptor is a continuation of an ADU frame that was too
           large to fit within a single RTP packet; 0 otherwise.
   -  "T": Descriptor Type flag (1 bit):
           0 if this is a 1-byte ADU descriptor;
           1 if this is a 2-byte ADU descriptor.
   -  "ADU size" (6 or 14 bits):
           The size (in bytes) of the ADU frame that will follow this
           ADU descriptor (i.e., NOT including the size of the
           descriptor itself).  A 2-byte ADU descriptor (with a 14-bit
           "ADU size" field) is used for ADU frames sizes of 64 bytes or
           more.  For smaller ADU frame sizes, senders MAY alternatively



Finlayson                   Standards Track                     [Page 3]

RFC 3119     Loss-Tolerant RTP Payload Format for MP3 Audio    June 2001


           use a 1-byte ADU descriptor (with a 6-bit "ADU size" field).
           Receivers MUST be able to accept an ADU descriptor of either
           size.

   Thus, a 1-byte ADU descriptor is formatted as follows:

          0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         |C|0|  ADU size |
         +-+-+-+-+-+-+-+-+

   and a 2-byte ADU descriptor is formatted as follows:

          0                   1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |C|1|     ADU size (14 bits)    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3 Packing rules

   Each RTP packet payload begins with a "ADU descriptor", followed by
   "ADU frame" data.  Normally, this "ADU descriptor"+"ADU frame" will
   fit completely within the RTP packet.  In this case, more than one
   successive "ADU descriptor"+"ADU frame" MAY be packed into a single
   RTP packet, provided that they all fit completely.

   If, however, a single "ADU descriptor"+"ADU frame" is too large to
   fit within an RTP packet, then the "ADU frame" is split across two or
   more successive RTP packets.  Each such packet begins with an ADU
   descriptor.  The first packet's descriptor has a "C" (continuation)
   flag of 0; the following packets' descriptors each have a "C" flag of
   1.  Each descriptor, in this case, has the same "ADU size" value: the
   size of the entire "ADU frame" (not just the portion that will fit
   within a single RTP packet).  Each such packet (even the last one)
   contains only one "ADU descriptor".

3.4 RTP header fields

      Payload Type: The (static) payload type 14 that was defined for
         MPEG audio [6] MUST NOT be used.  Instead, a different, dynamic
         payload type MUST be used - i.e., one in the range [96,127].

      M bit: This payload format defines no use for this bit.  Senders
         SHOULD set this bit to zero in each outgoing packet.

      Timestamp: This is a 32-bit 90 kHz timestamp, representing the
         presentation time of the first ADU packed within the packet.



Finlayson                   Standards Track                     [Page 4]

RFC 3119     Loss-Tolerant RTP Payload Format for MP3 Audio    June 2001


3.5 Handling received data

   Note that no information is lost by converting a sequence of MP3
   frames to a corresponding sequence of "ADU frames", so a receiving
   RTP implementation can either feed the ADU frames directly to an
   appropriately modified MP3 decoder, or convert them back into a
   sequence of MP3 frames, as described in appendix A.2 below.

4. Handling Multiple MPEG Audio Layers

   The RTP payload format described here is intended only for MPEG 1 or
   2, layer III audio ("MP3").  In contrast, layer I and layer II frames
   are self-contained, without a back-pointer to earlier frames.
   However, it is possible (although unusual) for a sequence of audio
   frames to consist of a mixture of layer III frames and layer I or II
   frames.  When such a sequence is transmitted, only layer III frames
   are converted to ADUs; layer I or II frames are sent 'as is' (except
   for the prepending of an "ADU descriptor").  Similarly, the receiver
   of a sequence of frames - using this payload format - leaves layer I
   and II frames untouched (after removing the prepended "ADU
   descriptor), but converts layer III frames from "ADU frames" to
   regular MP3 frames.  (Recall that each frame's layer is identified
   from its 4-byte MPEG header.)

   If you are transmitting a stream consists *only* of layer I or layer
   II frames (i.e., without any MP3 data), then there is no benefit to
   using this payload format, *unless* you are using the interleaving
   mechanism.

5. Frame Packetizing and Depacketizing

   The transmission of a sequence of MP3 frames takes the following
   steps:

         MP3 frames
                 -1-> ADU frames
                     -2-> interleaved ADU frames
                           -3-> RTP packets

   Step 1, the conversion of a sequence of MP3 frames to a corresponding
   sequence of ADU frames, takes place as described in sections 2 and
   3.1 above.  (Note also the pseudo-code in appendix A.1.)

   Step 2 is the reordering of the sequence of ADU frames in an
   (optional) interleaving pattern, prior to packetization, as described
   in section 6 below.  (Note also the pseudo-code in appendix B.1.)
   Interleaving helps reduce the effect of packet loss, by distributing
   consecutive ADU frames over non-consecutive packets.  (Note that



Finlayson                   Standards Track                     [Page 5]

RFC 3119     Loss-Tolerant RTP Payload Format for MP3 Audio    June 2001


   because of the back-pointer in MP3 frames, interleaving can be
   applied - in general - only to ADU frames.  Thus, interleaving was
   not possible for RFC 2250.)

   Step 3 is the packetizing of a sequence of (interleaved) ADU frames
   into RTP packets - as described in section 3.3 above.  Each packet's
   RTP timestamp is the presentation time of the first ADU that is
   packed within it.  Note that, if interleaving was done in step 2, the
   RTP timestamps on outgoing packets will not necessarily be
   monotonically nondecreasing.

   Similarly, a sequence of received RTP packets is handled as follows:

         RTP packets
               -4-> RTP packets ordered by RTP sequence number
                     -5-> interleaved ADU frames
                           -6-> ADU frames
                                 -7-> MP3 frames

   Step 4 is the usual sorting of incoming RTP packets using the RTP
   sequence number.

   Step 5 is the depacketizing of ADU frames from RTP packets - i.e.,
   the reverse of step 3.  As part of this process, a receiver uses the
   "C" (continuation) flag in the ADU descriptor to notice when an ADU
   frame is split over more than one packet (and to discard the ADU
   frame entirely if one of these packets is lost).

   Step 6 is the rearranging of the sequence of ADU frames back to its
   original order (except for ADU frames missing due to packet loss), as
   described in section 6 below.  (Note also the pseudo-code in appendix
   B.2.)

   Step 7 is the conversion of the sequence of ADU frames into a
   corresponding sequence of MP3 frames - i.e., the reverse of step 1.
   (Note also the pseudo-code in appendix A.2.)  With an appropriately
   modified MP3 decoder, an implementation may omit this step; instead,
   it could feed ADU frames directly to the (modified) MP3 decoder.

6. ADU Frame Interleaving

   In MPEG audio frames (MPEG 1 or 2; all layers) the high-order 11 bits
   of the 4-byte MPEG header ('syncword') are always all-one (i.e.,
   0xFFE).  When reordering a sequence of ADU frames for transmission,
   we reuse these 11 bits as an "Interleaving Sequence Number" (ISN).
   (Upon reception, they are replaced with 0xFFE once again.)





Finlayson                   Standards Track                     [Page 6]

RFC 3119     Loss-Tolerant RTP Payload Format for MP3 Audio    June 2001


   The structure of the ISN is (a,b), where:

         - a == bits 0-7:      8-bit Interleave Index (within Cycle)
         - b == bits 8-10:     3-bit Interleave Cycle Count

   I.e., the 4-byte MPEG header is reused as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Interleave Idx |CycCt|   The rest of the original MPEG header  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Example: Consider the following interleave cycle (of size 8):