Subject: Loss Tolerant MP3 Streaming

From: Chris Sloan <[email-masked]>
Date: Fri, 19 May 2000 17:54:46 -0700

Ross,

I am an employee of RealNetworks.  I am looking at your draft of "A More 
Loss Tolerant RTP Payload Format for MP3 Audio" and I would like to make 
suggestions on two things.

1. ADU Frame Interleaving
Instead of modifying the syncword to indicate the interleave cycle count 
and index, use one of the reserved bytes in the payload header.  As it 
stands today, there are two payload header bytes not being used by mpeg 
audio which are intended for uses such as this one.  Having worked with 
mpeg audio for years, tampering with the FFF? seems sacrilegious.

2. Frame Fragmentation
Since ADU frames vary in size, knowing when an ADU frame begins and ends is 
more useful than a fragmentation offset.  I propose adding ADU frame 
begin/end bits in the payload header the same way video slice begin/end 
bits are used for video slices in RFC 2250.   This way, the client can 
decode ADU frames directly from RTP packet buffers if the frames are 
self-contained.  Also, these bits would prevent the client from having to 
determine the size of the ADU frames by buffering RTP packets and looking 
at time stamps (and not messing up during packet loss).  If you are 
concerned with the number of available payload header bits, you can do away 
with the fragmentation offset bits and just use ADU frame begin/end bits.

These two changes would make it easier on developers writing MP3 servers
and clients, reduce the amount of buffering on the client side, and
preserve the integrity of the MP3 payload.

Please contact me with any questions or comments.
Thanks.

Chris Sloan
RealNetworks, Inc.
805 783 4916
[email-masked]

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 19 May 2000 21:48:57 -0700

Chris (cc. "rem-conf" et al),

I think you may have misinterpreted the description of the way that 'ADU 
frames' are packetized into RTP packets.

Let's start by reviewing the packetization of MPEG audio frames in RFC 
2250.  In RFC 2250, each RTP packet contains:
         1/ a regular RTP header
         2/ a 4-byte MPEG audio-specific header (see RFC 2250, section 3.5)
then either
         3a/ an *integral number* of MPEG frames
or
         3b/ a fragment of a single, fragmented MPEG frame
                 (with byte offset given by the "MPEG audio-specific header")

The new, alternative payload format for MP3 uses *exactly the same* 
packetization, except using "ADU frames" instead of "MPEG (MP3) 
frames".  (Note that "ADU frames" are defined in section 4 of the Internet 
Draft.)

This has the following consequences:

- The Interleave Cycle Count and Index - being properties of a (ADU) frame 
- cannot be stored in the RTP header (or MPEG audio-specific header), 
because there can be an arbitrary (integral) number of frames in a given 
RTP packet.  Instead, this information has to be stored within the frames 
themselves.  Fortunately, there are 'otherwise always-1' bits within the 
MPEG header that can be used to store this.  ('Tampering' with these bits 
isn't a problem, because it loses no information, and a receiver will 
always restore these bits (to 'all-1s') before they get fed to a decoder.)

- Except in case 3b (a single large frame being fragmented over more than 
one RTP packet), each RTP packet contains exactly an integral number of ADU 
frames.  So, these can be identified and extracted from the RTP packet 
immediately.

I think I am partially to blame for the confusion.  Because the new payload 
format is based so heavily upon RFC 2250, it seems clear to me now that the 
Internet Draft should have included an overview - similar to the one above 
- of RFC 2250's MPEG audio packetization scheme.  A familiarity with this 
is important for understanding the rest of the draft, so I'll be sure to 
add this to the next revision.

         Ross.