A More Loss-Tolerant RTP Payload Format for MP3 Audio
RFC 5219
Document | Type |
RFC - Proposed Standard
(February 2008; No errata)
Obsoletes RFC 3119
|
|
---|---|---|---|
Author | Ross Finlayson | ||
Last updated | 2015-10-14 | ||
Replaces | draft-finlayson-rtp-mp3 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5219 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Cullen Jennings | ||
Send notices to | (None) |
Network Working Group R. Finlayson Request for Comments: 5219 Live Networks, Inc. Obsoletes: 3119 February 2008 Category: Standard Track 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. Abstract This document describes an 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. This document obsoletes RFC 3119, correcting typographical errors in the "SDP usage" section and pseudo-code appendices. Finlayson Standards Track [Page 1] RFC 5219 February 2008 Table of Contents 1. Introduction ....................................................2 2. Terminology .....................................................3 3. The Structure of MP3 Frames .....................................3 4. A New Payload Format ............................................4 4.1. ADU Frames .................................................4 4.2. ADU Descriptors ............................................4 4.3. Packing Rules ..............................................5 4.4. RTP Header Fields ..........................................6 4.5. Handling Received Data .....................................6 5. Handling Multiple MPEG Audio Layers .............................6 6. Frame Packetizing and Depacketizing .............................7 7. ADU Frame Interleaving ..........................................8 8. IANA Considerations ............................................10 9. SDP Usage ......................................................11 10. Security Considerations .......................................11 11. Acknowledgements ..............................................11 12. Normative References ..........................................12 Appendix A. Translating between "MP3 Frames" and "ADU Frames" .....13 A.1. Converting a Sequence of "MP3 Frames" to a Sequence of "ADU Frames" .............................14 A.2. Converting a Sequence of "ADU Frames" to a Sequence of "MP3 Frames" .............................15 Appendix B. Interleaving and Deinterleaving .......................18 B.1. Interleaving a Sequence of "ADU Frames" ...................18 B.2. Deinterleaving a Sequence of (Interleaved) "ADU Frames" ...19 Appendix C. Changes from RFC 3119 .................................20 1. Introduction While the RTP payload format defined in RFC 2250 [1] 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 2] RFC 5219 February 2008 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. 3. The Structure of MP3 Frames In this section we give a brief overview of the structure of an MP3 frame. (For a 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.Show full document text