RFC 4184

RFC 4184: RTP Payload Format for AC-3 Audio 🎀

(part 1 of 3)

Okay bestie, let's do the paperwork first 💅 This is RFC 4184, called "RTP Payload Format for AC-3 Audio." It came out of the Network Working Group in October 2005 📅 and it's on the Standards Track 🚀. The authors are B. Link and T. Hager, both from Dolby Laboratories, and J. Flaks from Microsoft Corporation 🤝. The title block doesn't list anything it obsoletes or updates, so there's no older RFC it's replacing or patching 🦋

Status of This Memo ✨

This document describes an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 💬 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🌈

Copyright Notice 💜

Copyright (C) The Internet Society (2005).

Abstract 🌸

This document explains how to send AC-3 audio over RTP 🎧 AC-3 is a high-quality, multichannel audio coding system, and it shows up in US HDTV, DVD, cable TV, satellite TV, and more 📺 The payload format in this document supports data fragmentation, so a single frame can be split across packets when it needs to be ✂️

1. Introduction ✨

AC-3 [ATSC] is a high-quality audio codec (audio coding format) built to squish multiple audio channels into a low bit-rate format 🗜️ Its big compression wins come from encoding several channels as one single entity 🧠 Dolby Digital is the branded version of AC-3 and handles up to 5.1 channels 🔊

AC-3 is everywhere, bestie 😭 It's a mandatory audio codec for DVD-video, for Advanced Television Standards Committee (ATSC) digital terrestrial television, and for Digital Living Network Alliance (DLNA) home networking 🏠 It's also an optional multichannel audio format for DVD-audio 💿

We need to stream AC-3 over IP networks 🌐 The Internet Real Time Protocol (RTP) handles stream synchronization, which makes it the best transport pick for AC-3, since AC-3 is mostly used for audio that goes with video 🎬 Streaming AC-3 covers things like sending movies from a home media server to a display, video on demand, and multichannel Internet radio 📡

Here's the map 🗺️ Section 2 gives a quick overview of the AC-3 algorithm. Section 3 lists the values for RTP header fields, and Section 4 lays out the AC-3 payload format. Section 5 covers media types and SDP usage. Security considerations are in Section 6, congestion control is in Section 7, and IANA considerations are in Section 8. References are in Sections 9 and 10 📚

Now for the key words. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🫶

2. Overview of AC-3 🎶

AC-3 can deliver up to 5.1 channels of audio at data rates about half of one PCM channel [ATSC], [1994AC3], [1996AC3] 🤯 The ".1" is a band-limited, optional, low-frequency effects (LFE) channel, aka the subwoofer vibe 🔈 AC-3 was built for signals sampled at 32, 44.1, or 48 kHz 🎚️ Data rates can range from 32 kbps to 640 kbps, depending on how many channels you have and how good you want it to sound ✨

AC-3 uses psycho-acoustic phenomena, which is a fancy way of saying it exploits what your ears can't actually hear 👂 A big chunk of the information in a typical audio signal is inaudible, so removing it gives a lot of data reduction 🗑️ Source coding techniques cut the data rate even more 📉

Like most perceptual coders, AC-3 works in the frequency domain 🌊 It takes a 512-point TDAC transform with 50% overlap, which gives 256 new frequency samples 🧮 Those frequency samples get converted to exponents and mantissas. Exponents are differentially encoded. Mantissas get a varying number of bits based on how audible their spectral components are 🎧 Audibility comes from a masking curve, and the bits for mantissas come from a global bit pool 🫧

2.1. AC-3 Bit Stream 💖

AC-3 bit streams are organized into synchronization frames 🧱 Each AC-3 frame has a Synchronization Information (SI) field, a Bit Stream Information (BSI) field, and 6 audio blocks (ABs), where each block represents 256 PCM samples for all channels 🎹 The frame ends with an optional auxiliary data field (AUX) and an error correction field (CRC) 🛡️ The whole frame covers 1536 PCM samples across all coded channels ⏱️ AC-3 encodes audio sampled at 32 kHz, 44.1 kHz, and 48 kHz 🎵 According to Annex A, Part 2, of [ATSC], the frame duration changes with the sampling rate like this 👇

   Sampling rate          Frame duration
   _____________________________________
      48   kHz                32    ms
      44.1 kHz        approx. 34.83 ms
      32   kHz                48    ms

Figure 1 shows the AC-3 frame format 🖼️

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |SI |BSI|  AB0  |  AB1  |  AB2  |  AB3  |  AB4  |  AB5  |AUX|CRC|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1. AC-3 Frame Format

The Synchronization Information field has what's needed to acquire and keep codec synchronization 🔄 The Bit Stream Information field has the parameters that describe the coded audio service [ATSC] 📋 Each audio block has fields that show which coding tools are in use: block switching, dither, coupling, and exponent strategy 🛠️ Blocks also carry metadata, which can optionally enhance playback, like dynamic range control 🎚️ Lastly, each block includes the exponents and bit allocation data needed to decode the mantissas into audio, plus the mantissas themselves 🧩 Figure 2 shows where these fields sit in an AC-3 audio block. The fields in that figure are described in detail in [ATSC]. Heads up that field sizes change depending on the coded data 📏

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Block  |Dither |Dynamic    |Coupling |Coupling     |Exponent |
   |  Switch |Flags  |Range Ctrl |Strategy |Coordinates  |Strategy |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Exponents       | Bit Allocation  |        Mantissas      |
   |                     | Parameters      |                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2. AC-3 Audio Block Format

3. RTP AC-3 Header Fields 🎀

• Payload Type (PT): Assigning an RTP payload type for this packet format is outside the scope of this document 🙅 It's specified by the RTP profile this payload format is used under, or it's signaled dynamically out-of-band (e.g., using SDP) 📨
• Marker (M) bit: The M bit is set to one to say the RTP packet payload has at least one complete AC-3 frame, or it has the final fragment of an AC-3 frame 🏁
• Extension (X) bit: Defined by the RTP profile being used 🧩
• Timestamp: A 32-bit word that matches the sampling instant for the first AC-3 frame in the RTP packet ⏰ Packets with fragments of the same frame MUST have the same time stamp 🔒 The timestamp of the first RTP packet sent SHOULD be picked at random 🎲 After that, the timestamp goes up linearly with the number of samples in each frame, which means it goes up by 1536 for each frame 📈

4. RTP AC-3 Payload Format 💅

This payload format is defined for AC-3, as defined in the main part and Annex D of [ATSC] 🎯 It is NOT defined for E-AC-3, as defined in Annex E of [ATSC], and it MUST NOT be used to carry E-AC-3 🚫

Per [RFC2736], RTP payload formats should contain an integral number of application data units (ADUs) 📦 In this payload format, an AC-3 frame counts as an ADU 🙌 Each RTP payload MUST start with the two-byte payload header, followed either by an integral number of complete AC-3 frames or by a single fragment of an AC-3 frame 🧃

If an AC-3 frame is bigger than the MTU for a network, it SHOULD be fragmented for transmission inside an RTP packet ✂️ Section 4.2 has guidelines for making frame fragments 🧠

4.1. Payload-Specific Header 🫧

There is a two-octet Payload Header at the beginning of each payload 🎁

4.1.1. Payload Header 🌈

Each AC-3 RTP payload MUST begin with the payload header shown in Figure 3 💖

                  0                   1
                  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 |    MBZ    | FT|       NF      |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3. AC-3 RTP Payload Header

• MBZ (Must Be Zero): Bits marked MBZ SHALL be set to the value zero and SHALL be ignored by receivers 🙈 The bits are reserved for future extensions 🔮
• FT (Frame Type): This two-bit field shows the type of frame(s) in the payload 🎞️ It takes these values:

0 - One or more complete frames.
1 - Initial fragment of frame which includes the first 5/8ths of
    the frame.  (See Section 4.2.)
2 - Initial fragment of frame, which does not include the first
    5/8ths of the frame.
3 - Fragment of frame other than initial fragment.  (Note that M
    bit in RTP header is set for final fragment).

• NF (Number of frames/fragments): An 8-bit field whose meaning depends on the Frame Type (FT) in this payload 🔢 For complete frames (FT of 0), it shows the number of AC-3 frames in the RTP payload 📦 For frame fragments (FT of 1, 2, or 3), it shows the number of fragments (and therefore packets) that make up the current frame 🧩 NF MUST be identical for packets containing fragments of the same frame 🔒

Figure 4 shows the full AC-3 RTP payload format 🗂️

      +-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
      | Payload | Frame | Frame |     | Frame |
      | Header  |  (1)  |  (2)  |     |  (n)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+

Figure 4. Full AC-3 RTP payload

When a receiver gets AC-3 payloads with FT = 0 and more than a single frame (NF > 1), it needs to use the "frmsizecod" field in the Synchronization Information (syncinfo) block of each AC-3 frame to figure out that frame's length 🧐 That's how it finds where the next frame begins 🎯 Also, the frame length can change from frame to frame 🌊

4.2. Fragmentation of AC-3 Frames 💅

Okay so the size of an AC-3 frame depends on two things: the sample rate of the audio and the data rate the encoder is using. Both of those are listed in the "Synchronization Information" header inside the frame 🎧. For any given sample rate and data rate, the frame size is in Table 5.18 ("Frame Size Code Table") of [ATSC]. AC-3 frames range from a tiny 128 bytes all the way up to a chonky 3840 bytes 🦋. If a frame is bigger than the MTU, it SHOULD be fragmented at the RTP level. The fragmentation MAY happen at any byte boundary in the frame. The RTP packets carrying fragments of the same frame SHALL be sent in consecutive order, first fragment to last, so the receiver can put everything back together in the right order 🧩.

When an AC-3 frame gets fragmented, it MAY be fragmented so that at least the first 5/8ths of the frame data lands in the first fragment. This gives you way more resilience against packet loss 🛡️ That first chunk of any frame is guaranteed to have what's needed to decode the first two blocks of the frame. Any fragments past the first 5/8ths can only be decoded once the complete frame has arrived 😭 The 5/8ths point is defined in Table 7.34 ("5/8_frame Size Table") of [ATSC].

---

5. Types and Names 🎀

5.1. Media Type Registration

This registration uses the template from [DRAFT-FREED] and follows [RFC3555] 📝

• Type name: audio
• Subtype name: ac3
• Required parameters:
  • rate: This is the RTP timestamp clock rate, and it's equal to the audio sampling rate. The permitted rates are 32000, 44100, and 48000 ⏱️
• Optional parameters:
  • channels: From a sender, this is the maximum number of channels in the AC3 stream. From a receiver, it's the maximum number of output channels the receiver will deliver. This MUST be a number between 1 and 6. The LFE (".1") channel MUST be counted as one channel 🔊 Heads up, the channel order in AC-3 is different from the one in [RFC3551]. The AC-3 channel order scheme is in Table 5.8 of [ATSC].
  • ptime: See [RFC2327] 🕰️
  • maxptime: See [RFC3267] 🕰️
• Encoding considerations: This media type is framed (see section 4.8 in [DRAFT-FREED]) and contains binary data 🧱
• Security considerations: See Section 6 of this document 🔐
• Interoperability considerations: None ✨
• Published specification: This payload format specification, and see [ATSC] 📚
• Applications that use this media type: Multichannel audio compression of audio and audio for video 🎬
• Additional Information:
  • Magic number(s): The first two octets of an AC-3 frame are always the synchronization word, which has the hex value 0x0B77. Iykyk 🪄
• Person & email address to contact for further information: Brian Link <bdl@dolby.com>, IETF AVT working group 💌
• Intended Usage: COMMON 💖
• Restrictions on usage: This media type depends on RTP framing, so it's only defined for transfer via [RFC3550]. Transport within other framing protocols is not defined at this time 🚫

Author/Change controller: IETF Audio/Video Transport Working Group, delegated from the IESG 👑

5.2. SDP Usage

The info in the MIME media type spec has a specific mapping to fields in the Session Description Protocol (SDP) [RFC2327], which is what people usually use to describe RTP sessions. When you use SDP for sessions with AC-3, the mapping goes like this 🦋

• The media type (audio) goes in the SDP m= line as the media name.
• The media subtype (ac3) goes in the SDP a=rtpmap as the encoding name.
• The required parameter rate also goes in a=rtpmap as the clock rate, optionally followed by the parameter channel.
• The optional parameters ptime and maxptime go in the SDP a=ptime and a=maxptime attributes, respectively.

Here's an example of SDP data for AC-3 🌸

m=audio 49111 RTP/AVP 100
a=rtpmap:100 ac3/48000/6

Certain things need thinking about when you use SDP for offer/answer exchanges [RFC3264] 🤝

• The rate is a symmetric parameter, and the answer MUST use the same value or remove the payload type 🙅‍♀️
• The channels parameter is declarative. For recvonly or sendrecv, it shows the channel configuration you want to receive. For sendonly, it shows the channel configuration you intend to transmit. All receivers can receive any of the defined channel configurations, and the parameter exchange might be used to help optimize the transmission to the number of channels the receiver requests. If channels is omitted, a default maximum value of 6 is implied 🎧
• The ptime and maxptime parameters are negotiated as defined for ptime in [RFC3264] ⏱️

---

6. Security Considerations 🔐

This one's serious bestie, so read it carefully 🥹

This payload format is subject to the security considerations in the RTP specification [RFC3550] and in any applicable RTP profile (e.g., [RFC3551]). To protect the user's privacy and any copyrighted material, confidentiality protection would have to be applied. To also protect against modification by intermediate entities and make sure the stream is authentic, integrity protection and authentication would be required. Confidentiality, integrity protection, and authentication have to come from a mechanism outside this payload format, e.g., SRTP [RFC3711] 🛡️

The AC-3 format is designed so that decoders can determine whether a data frame is valid. A decoder that runs into a malformed frame throws away the malformed data and conceals the errors in the audio output until a valid frame is detected and decoded. This is expected to prevent crashes and other abnormal decoder behavior when errors or attacks show up 💀✨

---

7. Congestion Control 🌊

The general congestion control considerations for transporting RTP data apply to AC-3 audio over RTP too. Check out the RTP specification [RFC3550] and any applicable RTP profile (e.g., [RFC3551]) 🫶

AC-3 encoders may use a range of bit rates to encode audio data. That means you can adapt network bandwidth by adjusting the encoder bit rate in real time, or by having multiple copies of the content encoded at different bit rates 🎚️ Also, packing more frames into each RTP payload can cut down on the number of packets sent, and so reduce the overhead from IP/UDP/RTP headers. The tradeoff is more delay and less robustness against packet losses ⚖️

---

8. IANA Considerations 📋

A new media subtype has been assigned for AC-3; see Section 5.1 🎉

---

9. Normative References 📚

[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.

[ATSC] U.S. Advanced Television Systems Committee (ATSC), "ATSC Standard: Digital Audio Compression (AC-3), Revision B," Doc A/52B, June 2005.

[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

[RFC3267] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.

[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.

---

10. Informative References 🧠

[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, December 1999.

[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.

[1994AC3] Todd, C., et al., "AC-3: Flexible Perceptual Coding for Audio Transmission and Storage," Preprint 3796, Presented at the 96th Convention of the Audio Engineering Society, May 1994.

[1996AC3] Fielder, L., et al., "AC-2 and AC-3: Low-Complexity Transform-Based Audio Coding," Collected Papers on Digital Audio Bit-Rate Reduction, pp. 54-72, Audio Engineering Society, September 1996.

[RFC3711] Baugher, M., et al., "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

[DRAFT-FREED] Freed, N. and Klensin, J., "Media Type Specifications and Registration Procedures", Work in Progress, April 2005.

---

Authors' Addresses 💌

Brian Link
Dolby Laboratories
100 Potrero Ave
San Francisco, CA 94103

Phone: +1 415 558 0200
EMail: bdl@dolby.com


Todd Hager
Dolby Laboratories
100 Potrero Ave
San Francisco, CA 94103

Phone: +1 415 558 0136
EMail: thh@dolby.com


Jason Flaks
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052

Phone: +1 425 722 2543
EMail: jasonfl@microsoft.com

---

Full Copyright Statement 🌈

Copyright (C) The Internet Society (2005) 🦋

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights ✨

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💅

Intellectual Property ✨

okay so bestie, this part is all about legal stuff 💅 The IETF doesn't take a side on whether any Intellectual Property Rights or other rights might apply to the tech in this document, or whether any license under those rights is actually available. It also doesn't claim it went hunting for those rights itself 🙈 If you want the procedures for rights in RFC documents, check out BCP 78 and BCP 79, they're the official rulebook 📖

Copies of IPR disclosures sent to the IETF Secretariat live in the IETF online IPR repository at http://www.ietf.org/ipr. That's also where you'd find any assurances of licenses, or the results of anyone trying to get a general license or permission to use the proprietary stuff. Implementers and users can look there too 🫶

The IETF also invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement ✨

The RFC Editor function is currently funded by the Internet Society 🌈 Thank you, Internet Society 💖