A More Loss-Tolerant RTP Payload Format for MP3 Audio
RFC 5219
| Document | Type |
RFC - Proposed Standard
(February 2008; No errata)
Obsoletes RFC 3119
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Replaces | draft-finlayson-rtp-mp3 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| 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
Show full document text