Subject: Updated MP3/RTP Internet Draft submitted

From: Ross Finlayson <[email-masked]>
Date: Tue, 19 Oct 1999 20:33:23 -0700

FYI, I have submitted a updated version of the "A More Loss-Tolerant RTP
Payload Format for MP3 Audio" Internet Draft.  The major changes
(additions) to the draft are:
- a brief section describing how to deal with (unusual) streams that mix
layer I and II audio frames with layer III frames.
- an appendix with 'pseudo code' that describes how to convert a stream of
regular MP3 frames into "ADU frames", or vice-versa.

Until the draft is announced (likely as <draft-ietf-avt-rtp-mp3-01.txt>),
you can find it online at <http://www.live.com/rtp-mp3/rtp-mp3.txt>.  (For
an illustration - with MP3 files - of the benefits of the new format, see
<http://www.live.com/rtp-mp3/>)

I'm interested in any feedback on this draft, especially from MP3 experts
(e.g., at Fraunhofer), or from others who are working on implementations. 

	Ross.

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.