A More Loss-Tolerant RTP Payload Format for MP3 Audio
draft-finlayson-rtp-mp3-00
Document | Type |
Replaced Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Author | Dr. Ross Finlayson | ||
Last updated | 2009-02-24 (Latest revision 1999-02-24) | ||
Replaced by | draft-ietf-avt-rfc3119bis | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Replaced by draft-ietf-avt-rfc3119bis | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
While the RTP payload format defined in RFC 2250 is generally applicable to all forms of MPEG audio or video, it is less suitable 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 a new RTP payload format for MP3 audio. The new format is essentially the same as that defined in RFC 2250, except for a data-preserving rearrangement of the original MPEG frames, so that packet boundaries now coincide with true MP3 'Application Data Units'. This new format is therefore more data efficient in the face of packet loss.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)