idnits 2.17.1 draft-ietf-avt-rtp-mp3-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 698 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 272 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 135: '...e sizes, senders MAY alternatively use...' RFC 2119 keyword, line 136: '...bit "ADU size" field). Receivers MUST...' RFC 2119 keyword, line 159: '...tor"+"ADU frame" MAY be packed into a ...' RFC 2119 keyword, line 174: '...ifferent, dynamic payload type MUST be...' RFC 2119 keyword, line 308: '... of this payload format MUST recognize...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '96' is mentioned on line 175, but not defined == Missing Reference: '127' is mentioned on line 175, but not defined == Missing Reference: '256' is mentioned on line 619, but not defined == Missing Reference: '0' is mentioned on line 658, but not defined == Missing Reference: '255' is mentioned on line 656, but not defined == Missing Reference: '15' is mentioned on line 658, but not defined ** Obsolete normative reference: RFC 1890 (ref. '5') (Obsoleted by RFC 3551) ** Obsolete normative reference: RFC 2327 (ref. '6') (Obsoleted by RFC 4566) Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ross Finlayson 2 Internet-Draft LIVE.COM 3 Expire in six months 2000.07.13 4 Category: Informational 6 A More Loss-Tolerant RTP Payload Format for MP3 Audio 8 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 2. Abstract 34 While the RTP payload format defined in RFC 2250 is generally applicable 35 to all forms of MPEG audio or video, it is less suitable for MPEG 1 36 or 2, layer III audio (commonly known as "MP3"). The reason for this is 37 that an MP3 frame is not a true "Application Data Unit" - it contains a 38 back-pointer to data in earlier frames, and so cannot be decoded 39 independently of these earlier frames. Because RFC 2250 defines that 40 packet boundaries coincide with frame boundaries, it handles packet loss 41 inefficiently when carrying MP3 data. The loss of an MP3 frame will 42 render some data in previous (or future) frames useless, even if they 43 are received without loss. 45 In this document we define an alternative RTP payload format for MP3 46 audio. This format uses a data-preserving rearrangement of the original 47 MPEG frames, so that packet boundaries now coincide with true MP3 48 "Application Data Units", which can also (optionally) be rearranged in 49 an interleaving pattern. This new format is therefore more 50 data-efficient than RFC 2250 in the face of packet loss. 52 3. The Structure of MP3 Frames 54 In this section we give a brief overview of the structure of a MP3 frame. 55 (For more detailed description, see the official MPEG 1 audio [2] and 56 MPEG 2 audio [3] specifications.) 58 Each MPEG audio frame begins with a 4-byte header. Information defined by 59 this header includes: 60 - Whether the audio is MPEG 1 or MPEG 2. 61 - Whether the audio is layer I, II, or III. 62 (The remainder of this document assumes layer III, i.e., "MP3") 63 - Whether the audio is mono or stereo. 64 - Whether or not there is a 2-byte CRC field following the header. 65 - (indirectly) The size of the frame. 67 The following structures appear after the header: 68 - (optionally) A 2-byte CRC field 69 - A "side info" structure. This has the following length: 70 - 32 bytes for MPEG 1 stereo 71 - 17 bytes for MPEG 1 mono, or for MPEG 2 stereo 72 - 9 bytes for MPEG 2 mono 73 - Encoded audio data, plus optional ancillary data 74 (filling out the rest of the frame) 76 For the purpose of this document, the "side info" structure is the most 77 important, because it defines the location and size of the "Application 78 Data Unit" (ADU) that an MP3 decoder will process. In particular, the 79 "side info" structure defines: 80 - "main_data_begin": This is a back-pointer (in bytes) to the start of the 81 ADU. The back-pointer is counted from the beginning of the frame, 82 and counts only encoded audio data and any ancillary data 83 (i.e., ignoring any header, CRC, or "side info" fields). 85 An MP3 decoder processes each ADU independently. The ADUs will generally 86 vary in length, but their average length will, of course, be that of the 87 of the MP3 frames (minus the length of the header, CRC, and "side info" 88 fields). (In MPEG literature, this ADU is sometimes referred to as 89 a "bit reservoir".) 91 4. A New Payload Format 93 4.1 ADU frames 95 As noted in [4], a payload format should be designed so that packet 96 boundaries coincide with "codec frame boundaries" - i.e., with ADUs. 97 In the RFC 2250 payload format for MPEG audio [1], each RTP packet 98 payload contains MP3 frames. In this new payload format for MP3 audio, 99 however, each RTP packet payload contains "ADU frames", where an 100 "ADU frame" is defined as: 101 - The 4-byte MPEG header 102 (the same as the original MP3 frame, except that the 103 first 12 bits is replaced with an "interleaving index", 104 as described in section 7) 105 - The optional 2-byte CRC field 106 (the same as the original MP3 frame) 107 - The "side info" structure 108 (the same as the original MP3 frame) 109 - The complete sequence of encoded audio data (and any ancillary 110 data) for the ADU (i.e., running from the start of this 111 MP3 frame's "main_data_begin" back-pointer, up to the 112 start of the next MP3 frame's back-pointer) 114 4.2 ADU descriptors 116 Within each RTP packet payload, each "ADU frame" is prepended by a 117 1 or 2-byte "ADU descriptor", which gives the size of the ADU, and 118 indicates whether or not this packet's data is a continuation of the 119 previous packet's data. (This occurs only when a single 120 "ADU descriptor"+"ADU frame" is too large to fit within a RTP packet.) 122 An ADU descriptor consists of the following fields 123 - "C": Continuation flag (1 bit): 124 1 if the data following the ADU descriptor is a continuation of 125 an ADU frame that was too large to fit within a single RTP 126 packet; 0 otherwise. 127 - "T": Descriptor Type flag (1 bit): 128 0 if this is a 1-byte ADU descriptor; 129 1 if this is a 2-byte ADU descriptor. 130 - "ADU size" (6 or 14 bits): 131 The size (in bytes) of the ADU frame that will follow this 132 ADU descriptor (i.e., NOT including the size of the descriptor 133 itself). A 2-byte ADU descriptor (with a 14-bit "ADU size" 134 field) is used for ADU frames sizes of 64 bytes or more. For 135 smaller ADU frame sizes, senders MAY alternatively use a 1-byte 136 ADU descriptor (with a 6-bit "ADU size" field). Receivers MUST 137 be able to accept an ADU descriptor of either size. 139 Thus, a 1-byte ADU descriptor is formatted as follows: 141 0 1 2 3 4 5 6 7 142 +-+-+-+-+-+-+-+-+ 143 |C|0| ADU size | 144 +-+-+-+-+-+-+-+-+ 146 and a 2-byte ADU descriptor is formatted as follows: 148 0 1 149 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 |C|1| ADU size (14 bits) | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 4.3 Packing rules 156 Each RTP packet payload begins with a "ADU descriptor", followed by 157 "ADU frame" data. Normally, this "ADU descriptor"+"ADU frame" will 158 fit completely within the RTP packet. In this case, more than one 159 successive "ADU descriptor"+"ADU frame" MAY be packed into a single RTP 160 packet, provided that they all fit completely. 162 If, however, a single "ADU descriptor"+"ADU frame" is too large to fit 163 within an RTP packet, then it is split across two or more successive RTP 164 packets. Each such packet begins with an ADU descriptor. The first 165 packet's descriptor has a "C" (continuation) flag of 0; the following 166 packets' descriptors each have a "C" flag of 1. Each descriptor has the 167 same "ADU size" value: the size of entire "ADU frame" (not just the 168 portion that will fit within a single RTP packet). Each such packet 169 (even the last one) contains only one "ADU descriptor". 171 4.4 RTP payload type 173 The (static) payload type 14 that was defined for MPEG audio [5] 174 MUST NOT be used. Instead, a different, dynamic payload type MUST be 175 used - i.e., one in the range [96,127]. 177 4.5 Handling received data 179 Note that no information is lost by converting a sequence of MP3 frames to 180 a corresponding sequence of "ADU frames", so a receiving RTP implementation 181 can either feed the ADU frames directly to an appropriately modified MP3 182 decoder, or convert them back into a sequence of MP3 frames, as described 183 in appendix A.2 below. 185 5. Handling Multiple MPEG Audio Layers 187 The RTP payload format described here is intended only for MPEG 1 or 2, 188 layer III audio ("MP3"). In contrast, layer I and layer II frames are 189 self-contained, without a back-pointer to earlier frames. However, it 190 is possible (although unusual) for a sequence of audio frames to consist 191 of a mixture of layer III frames and layer I or II frames. When such a 192 sequence is transmitted, only layer III frames are converted to ADUs; 193 layer I or II frames are sent 'as is' (except for the prepending of an 194 "ADU descriptor"). Similarly, the receiver of a sequence of frames 195 - using this payload format - leaves layer I and II frames untouched 196 (after removing the prepended "ADU descriptor), but converts layer III 197 frames from "ADU frames" to regular MP3 frames. (Recall that each 198 frame's layer is identified from its 4-byte MPEG header.) 200 6. Frame Packetizing and Depacketizing 202 The transmission of a sequence of MP3 frames takes the following steps: 203 MP3 frames 204 -1-> ADU frames 205 -2-> interleaved ADU frames 206 -3-> RTP packets 208 Step 1, the conversion of a sequence of MP3 frames to a corresponding 209 sequence of ADU frames, takes place as described in sections 3 and 4.1. 210 (Note also the pseudo-code in appendix A.1.) 212 Step 2 is the reordering of the sequence of ADU frames in an 213 (optional) interleaving pattern, prior to packetization, as described 214 in section 7 below. (Note also the pseudo-code in appendix B.1.) 215 Interleaving helps reduce the effect of packet loss, by distributing 216 consecutive ADU frames over more than one packet. (Note that because 217 of the back-pointer in MP3 frames, interleaving can be applied 218 - in general - only to ADU frames. Thus, interleaving was not possible 219 for RFC 2250.) 221 Step 3 is the packetizing of a sequence of (interleaved) ADU frames 222 into RTP packets - as described in section 4.3 above. When computing 223 the RTP timestamps for each packet, this step ignores any reordering 224 that took place in step 2, and treats the sequence of packetized 225 ADU frames as if they were generated sequentially. I.e., the RTP 226 timestamps on outgoing packets are always monotonically nondecreasing, 227 regardless of interleaving. 229 Similarly, a sequence of received RTP packets is handled as follows: 230 RTP packets 231 -4-> RTP packets ordered by RTP sequence number 232 -5-> interleaved ADU frames 233 -6-> ADU frames 234 -7-> MP3 frames 236 Step 4 is the usual sorting of incoming RTP packets using the RTP 237 sequence number. 239 Step 5 is the depacketizing of ADU frames from RTP packets - i.e., the 240 reverse of step 3. As part of this process, a receiver uses the "C" 241 (continuation) flag in the ADU descriptor to notice when an ADU frame 242 is split over more than one packet (and to discard the ADU frame 243 entirely if one of these packets is lost). 245 Step 6 is the rearranging of the sequence of ADU frames back to its 246 original order (except for ADU frames missing due to packet loss), 247 as described in section 7 below. (Note also the pseudo-code in 248 appendix B.2.) 250 Step 7 is the conversion of the sequence of ADU frames into a 251 corresponding sequence of MP3 frames - i.e., the reverse of step 1. 252 (Note also the pseudo-code in appendix A.2.) With an appropriately 253 modified MP3 decoder, an implementation may omit this step; instead, 254 it could feed ADU frames directly to the (modified) MP3 decoder. 256 7. ADU Frame Interleaving 258 In MPEG audio frames (MPEG 1 or 2; all layers) the high-order 12 bits of 259 the 4-byte MPEG header ('syncword') is always 0xFFF. When reordering 260 a sequence of ADU frames for transmission, we reuse these 12 bits as an 261 "Interleaving Sequence Number" (ISN). (Upon reception, they are 262 replaced with 0xFFF once again.) 264 The structure of the ISN is (a,b), where: 265 - a == bits 0-8: 8-bit Interleave Index (within Cycle) 266 - b == bits 9-12: 4-bit Interleave Cycle Count 268 I.e., the 4-byte MPEG header is reused as follows: 270 0 1 2 3 271 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 |Interleave Idx |Cycle Cnt| The rest of the original MPEG header| 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Example: An interleave cycle of size 8, with a stride of 4, would have 277 a pattern of: 0,4,2,6,1,5,3,7 - giving the following sequence of ISNs: 278 (0,0) (4,0) (2,0) (6,0) (1,0) (5,0) (3,0) (7,0) (0,1) (4,1) (2,1) etc. 279 So, in this example, a sequence of ADU frames 280 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 (etc.) 281 would get reordered, in step 2, into: 282 (0,0)f0 (4,0)f4 (2,0)f2 (6,0)f6 (1,0)f1 (5,0)f5 (3,0)f3 (7,0)f7 283 (0,1)f8 (4,1)f12 (2,1)f10 (etc.) 284 and the reverse reordering (along with replacement of the 0xFFF) would 285 occur upon reception. 287 The reason for breaking the ISN into "Interleave Cycle Count" and 288 "Interleave Index" (rather than just treating it as a single 12-bit 289 counter) is to give receivers a way of knowing when an ADU frame 290 should be 'released' to the ADU->MP3 conversion process (step 7 291 above), rather than waiting for more interleaved ADU frames to arrive. 292 E.g., in the example above, when the receiver sees a frame with 293 ISN (,1), it knows that it can release all previously-seen 294 frames with ISN (,0), even if some other (,0) 295 frames remain missing due to packet loss. A 8-bit Interleave Index 296 allows interleave cycles of size up to 256. 298 The choice of an interleaving order can be made independently of RTP 299 packetization. Thus, a simple implementation could choose an 300 interleaving order first, reorder the ADU frames accordingly (step 2), 301 then simply pack them sequentially into RTP packets (step 3). However, 302 the size of ADU frames - and thus the number of ADU frames that will 303 fit in each RTP packet - will typically vary in size, so a more optimal 304 implementation would combine steps 2 and 3, by choosing an interleaving 305 order that better reflected the number of ADU frames packed within 306 each RTP packet. 308 Each receiving implementation of this payload format MUST recognize 309 the ISN and be able to perform deinterleaving of incoming ADU frames 310 (step 6). However, a sending implementation of this payload format 311 MAY choose not to perform interleaving - i.e., by omitting step 2. 312 In this case, the high-order byte in each 4-byte MPEG header would 313 remain at 0xFFF. Receiving implementations would thus see a sequence 314 of identical ISNs (all 0xFFF), treat this as if the Interleave Cycle 315 Count had wrapped-around, and simply release the sequence of incoming 316 ADU frames sequentially to the ADU->MP3 conversion process (step 7), 317 without reordering. 319 8. SDP Payload Format Description 321 Pending any future standardization of this payload format, SDP "rtpmap" 322 attributes [6] use the name "X-MP3" to denote this format. 324 9. Security Considerations 326 The security considerations for this payload format are identical to 327 those noted for RFC 2250 [1]. 329 10. Acknowledgements 331 The suggestion of adding an interleaving option (using the first bits 332 of the MPEG 'syncword' - which would otherwise be all-ones - as an 333 interleaving index) is due to Dave Singer and Stefan Gewinner. Feedback 334 from Chris Sloan led to the addition of an "ADU descriptor" preceding 335 each ADU frame in the RTP packet. 337 11. References 339 [1] Hoffman, D., Fernando, G., Goyal, V., and Civanlar, M. 340 "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998. 341 [2] ISO/IEC International Standard 11172-3; "Coding of moving pictures 342 and associated audio for digital storage media up to about 1,5 343 Mbits/s - Part 3: Audio", 1993. 344 [3] ISO/IEC International Standard 13818-3; "Generic coding of moving 345 pictures and associated audio information - Part 3: Audio", 1998. 346 [4] Handley, M. 347 "Guidelines for Writers of RTP Payload Format Specifications" 348 Work-in-Progress, Internet-Draft 349 "draft-ietf-avt-rtp-format-guidelines-04.txt", October 1999. 350 [5] Schulzrinne, H. 351 "RTP Profile for Audio and Video Conferences with Minimal Control" 352 RFC 1890, January 1996. 353 [6] Handley, M., Jacobson, V., 354 "SDP: Session Description Protocol", 355 RFC 2327, April 1998. 357 9. Author's Address 359 Ross Finlayson, 360 Live Networks, Inc. (LIVE.COM) 361 email: finlayson@live.com 362 WWW: http://www.live.com/ 364 Appendix A. Translating Between "MP3 Frames" and "ADU Frames" 366 The following 'pseudo code' describes how a sender using this payload 367 format can translate a sequence of regular "MP3 Frames" to "ADU Frames", 368 and how a receiver can perform the reverse translation: from "ADU Frames" 369 to "MP3 Frames". 371 We first define the following abstract data structures: 373 - "Segment": A record that represents either a "MP3 Frame" or an 374 "ADU Frame". It consists of the following fields: 375 - "header": the 4-byte MPEG header 376 - "headerSize": a constant (== 4) 377 - "sideInfo": the 'side info' structure, *including* the optional 378 2-byte CRC field, if present 379 - "sideInfoSize": the size (in bytes) of the above structure 380 - "frameData": the remaining data in this frame 381 - "frameDataSize": the size (in bytes) of the above data 382 - "backpointer": the size (in bytes) of the backpointer for 383 this frame 384 - "aduDataSize": the size (in bytes) of the ADU associated with 385 this frame. (If the frame is already an "ADU Frame", then 386 aduDataSize == frameDataSize) 387 - "mp3FrameSize": the total size (in bytes) that this frame would 388 have if it were a regular "MP3 Frame". 389 (If it is already a "MP3 Frame", then 390 mp3FrameSize == headerSize + sideInfoSize + frameDataSize) 391 Note that this size can be derived completely from "header". 393 - "SegmentQueue": A FIFO queue of "Segment"s, with operations 394 - void enqueue(Segment) 395 - Segment dequeue() 396 - Boolean isEmpty() 397 - Segment head() 398 - Segment tail() 399 - Segment previous(Segment): 400 returns the segment prior to a given one 401 - Segment next(Segment): returns the segment after a given one 402 - unsigned totalDataSize(): returns the sum of the "frameDataSize" 403 fields of each entry in the queue 405 A.1 Converting a sequence of "MP3 Frames" to a sequence of "ADU Frames": 407 SegmentQueue pendingMP3Frames; // initially empty 408 while (1) { 409 // Enqueue new MP3 Frames, until we have enough data to generate 410 // the ADU for a frame: 411 do { 412 int totalDataSizeBefore 413 = pendingMP3Frames.totalDataSize(); 415 Segment newFrame = 'the next MP3 Frame'; 416 pendingMP3Frames.enqueue(newFrame); 418 int totalDataSizeAfter 419 = pendingMP3Frames.totalDataSize(); 420 } while (totalDataSizeBefore < newFrame.backpointer || 421 totalDataSizeAfter < newFrame.aduDataSize); 423 // We now have enough data to generate the ADU for the most 424 // recently enqueued frame (i.e., the tail of the queue). 425 // (The earlier frames in the queue - if any - must be discarded, 426 // as we don't have enough data to generate their ADUs.) 427 Segment tailFrame = pendingMP3Frames.tail(); 429 // Output the header and side info: 430 output(tailFrame.header); 431 output(tailFrame.sideInfo); 433 // Go back to the frame that contains the start of our ADU data: 434 int offset = 0; 435 Segment curFrame = tailFrame; 436 int prevBytes = tailFrame.backpointer; 437 while (prevBytes > 0) { 438 curFrame = pendingMP3Frames.previous(curFrame); 439 int dataHere = curFrame.frameDataSize; 440 if (dataHere < prevBytes) { 441 prevBytes -= dataHere; 442 } else { 443 offset = dataHere - prevBytes; 444 break; 445 } 446 } 448 // Dequeue any frames that we no longer need: 449 while (pendingMP3Frames.head() != curFrame) { 450 pendingMP3Frames.dequeue(); 451 } 453 // Output, from the remaining frames, the ADU data that we want: 454 int bytesToUse = tailFrame.aduDataSize; 455 while (bytesToUse > 0) { 456 int dataHere = curFrame.frameDataSize - offset; 457 int bytesUsedHere 458 = dataHere < bytesToUse ? dataHere : bytesToUse; 460 output("bytesUsedHere" bytes from curFrame.frameData, 461 starting from "offset"); 463 bytesToUse -= bytesUsedHere; 464 offset = 0; 465 curFrame = pendingMP3Frames.next(curFrame); 466 } 467 } 469 A.2 Converting a sequence of "ADU Frames" to a sequence of "MP3 Frames": 471 SegmentQueue pendingADUFrames; // initially empty 472 while (1) { 473 while (needToGetAnADU()) { 474 Segment newADU = 'the next ADU Frame'; 475 pendingADUFrames.enqueue(newADU); 477 insertDummyADUsIfNecessary(); 478 } 480 generateFrameFromHeadADU(); 481 } 483 Boolean needToGetAnADU() { 484 // Checks whether we need to enqueue one or more new ADUs before 485 // we have enough data to generate a frame for the head ADU. 486 Boolean needToEnqueue = True; 488 if (!pendingADUFrames.isEmpty()) { 489 Segment curADU = pendingADUFrames.head(); 490 int endOfHeadFrame = curADU.mp3FrameSize 491 - curADU.headerSize - curADU.sideInfoSize; 492 int frameOffset = 0; 494 while (1) { 495 int endOfData = frameOffset 496 - curADU.backpointer + curADU.aduDataSize; 497 if (endOfData >= endOfHeadFrame) { 498 // We have enough data to generate a frame. 499 needToEnqueue = False; 500 break; 501 } 503 frameOffset += curADU.mp3FrameSize 504 - curADU.headerSize - curADU.sideInfoSize; 505 if (curADU == pendingADUFrames.tail()) break; 506 curADU = pendingADUFrames.next(curADU); 507 } 508 } 510 return needToEnqueue; 511 } 513 void generateFrameFromHeadADU() { 514 Segment curADU = pendingADUFrames.head(); 516 // Output the header and side info: 517 output(curADU.header); 518 output(curADU.sideInfo); 520 // Begin by zeroing out the rest of the frame, in case the ADU 521 // data doesn't fill it in completely: 522 int endOfHeadFrame = curADU.mp3FrameSize 523 - curADU.headerSize - curADU.sideInfoSize; 524 output("endOfHeadFrame" zero bytes); 526 // Fill in the frame with appropriate ADU data from this and 527 // subsequent ADUs: 528 int frameOffset = 0; 529 int toOffset = 0; 531 while (toOffset < endOfHeadFrame) { 532 int startOfData = frameOffset - curADU.backpointer; 533 if (startOfData > endOfHeadFrame) { 534 break; // no more ADUs are needed 535 } 536 int endOfData = startOfData + curADU.aduDataSize; 537 if (endOfData > endOfHeadFrame) { 538 endOfData = endOfHeadFrame; 539 } 541 int fromOffset; 542 if (startOfData <= toOffset) { 543 fromOffset = toOffset - startOfData; 544 startOfData = toOffset; 545 if (endOfData < startOfData) { 546 endOfData = startOfData; 547 } 548 } else { 549 fromOffset = 0; 551 // leave some zero bytes beforehand: 552 toOffset = startOfData; 553 } 555 int bytesUsedHere = endOfData - startOfData; 556 output(starting at offset "toOffset, "bytesUsedHere" bytes 557 from "&curADU.frameData[fromOffset]"); 558 toOffset += bytesUsedHere; 560 frameOffset += curADU.mp3FrameSize 561 - curADU.headerSize - curADU.sideInfoSize; 562 curADU = pendingADUFrames.next(curADU); 563 } 565 pendingADUFrames.dequeue(); 566 } 568 void insertDummyADUsIfNecessary() { 569 // The tail segment (ADU) is assumed to have been recently 570 // enqueued. If its backpointer would overlap the data 571 // of the previous ADU, then we need to insert one or more empty, 572 // 'dummy' ADUs ahead of it. (This situation should occur only if 573 // an intermediate ADU was missing - e.g., due to packet loss.) 574 while (1) { 575 Segment tailADU = pendingADUFrames.tail(); 576 int prevADUend; // relative to the start of the tail ADU 578 if (pendingADUFrames.head() != tailADU) { 579 // there is a previous ADU 580 Segment prevADU 581 = pendingADUFrames.previous(tailADU); 582 prevADUend 583 = prevADU.mp3FrameSize + prevADU.backpointer 584 - prevADU.headerSize - curADU.sideInfoSize; 585 if (prevADU.aduDataSize > prevADUend) { 586 // this shouldn't happen if the previous ADU 587 // was well-formed 588 prevADUend = 0; 589 } else { 590 prevADUend -= prevADU.aduDataSize; 591 } 592 } else { 593 prevADUend = 0; 594 } 596 if (tailADU.backpointer > prevADUend) { 597 // Insert a 'dummy' ADU in front of the tail. 598 // This ADU can have the same "header" (and thus 599 // "mp3FrameSize") as the tail ADU, but should have 600 // an "aduDataSize" of zero. The simplest way to do 601 // this is to copy the "sideInfo" from the tail ADU, 602 // and zero out the "main_data_begin" and all of the 603 // "part2_3_length" fields. 604 } else { 605 break; // no more dummy ADUs need to be inserted 606 } 607 } 608 } 610 Appendix B: Interleaving and Deinterleaving 612 The following 'pseudo code' describes how a sender can reorder a 613 sequence of "ADU Frames" according to an interleaving pattern (step 2), 614 and how a receiver can perform the reverse reordering (step 6). 616 B.1 Interleaving a sequence of "ADU Frames": 618 We first define the following abstract data structures: 619 - "interleaveCycleSize": an integer in the range [1,256] 620 - "interleaveCycle": an array, of size "interleaveCycleSize", 621 containing some permutation of the integers from the set 622 [0 .. interleaveCycleSize-1] 623 e.g., if "interleaveCycleSize" == 8, "interleaveCycle" might 624 contain: 0,4,2,6,1,5,3,7 625 - "inverseInterleaveCycle": an array containing the inverse of the 626 permutation in "interleaveCycle" - i.e., such that 627 interleaveCycle[inverseInterleaveCycle[i]] == i 628 - "ii": the current Interleave Index (initially 0) 629 - "icc": the current Interleave Cycle Count (initially 0) 630 - "aduFrameBuffer": an array, of size "interleaveCycleSize", of 631 ADU Frames that are awaiting packetization 633 while (1) { 634 int currentISN = inverseInterleaveCycle[ii]; 635 aduFrameBuffer[currentISN] = the next ADU frame; 636 replace the high-order 12 bits of this frame's MPEG header 637 with (ii,icc); 638 if (++ii == interleaveCycleSize) { 639 // we've finished this cycle, so pass all 640 // pending frames to the packetizing step 641 for (int i = 0; i < interleaveCycleSize; ++i) { 642 pass aduFrameBuffer[i] to the packetizing step; 643 } 645 ii = 0; 646 icc = (icc+1)&0xF; 647 } 648 } 650 B.2 Deinterleaving a sequence of (interleaved) "ADU Frames": 652 We first define the following abstract data structures: 653 - "ii": the Interleave Index from the current incoming ADU frame 654 - "icc": the Interleave Cycle Count from the current incoming ADU frame 655 - "iiLastSeen": the most recently seen Interleave Index 656 (initially, some integer *not* in the range [0,255]) 657 - "iccLastSeen": the most recently seen Interleave Cycle Count 658 (initially, some integer *not* in the range [0,15]) 659 - "aduFrameBuffer": an array, of size 32, of (pointers to) 660 ADU Frames that have just been depacketized 661 (initially, all entries are NULL) 663 while (1) { 664 aduFrame = the next ADU frame from the depacketizing step; 665 (ii,icc) = "the high-order 12 bits of aduFrame's MPEG header"; 666 "the high-order 12 bits of aduFrame's MPEG header" = 0xFFF; 667 // Note: Be sure to leave the remaining 20 bits as is 669 if (icc != iccLastSeen || ii == iiLastSeen) { 670 // We've started a new interleave cycle 671 // (or interleaving was not used). Release all 672 // pending ADU frames to the ADU->MP3 conversion step: 673 for (int i = 0; i < 32; ++i) { 674 if (aduFrameBuffer[i] != NULL) { 675 release aduFrameBuffer[i]; 676 aduFrameBuffer[i] = NULL; 677 } 678 } 679 } 681 iiLastSeen = ii; 682 iccLastSeen = icc; 683 aduFrameBuffer[ii] = aduFrame; 684 }