RFC 4598

Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio

📅 published July 2006, from ietf

Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio 🦋

okay bestie, this one is the RTP payload format for Enhanced AC-3 (E-AC-3) audio 🎧✨. here's the title block so you know who's behind it:

  • Network Working Group 🌸
  • Request for Comments: 4598
  • Author: B. Link, Dolby Laboratories 💖
  • Category: Standards Track 👑
  • Date: July 2006 📅
  • Obsoletes / Updates: the header doesn't list anything this one obsoletes or updates 🙈

Status of This Memo 📜

so this document is an Internet standards track protocol for the Internet community 🌈. it's also asking people to discuss it and send in suggestions for improvements 💅. if you want to know where it stands in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🧚. and distribution of this memo is unlimited, so share it with everyone 💜.

Copyright (C) The Internet Society (2006). ✨

Abstract 🎀

this doc describes an RTP payload format for carrying Enhanced AC-3 (E-AC-3) encoded audio data 🎶. E-AC-3 is a high-quality, multichannel audio coding format, and it's an extension of AC-3, which shows up in US High-Definition Television (HDTV), DVD, cable and satellite TV, and other media 📺. E-AC-3 is an optional audio format in US and worldwide digital television and high-definition DVD formats 🍓. the RTP payload format in this document supports data fragmentation 🫶.

Table of Contents 🗂️

   1. Introduction ....................................................2
   2. Overview of Enhanced-AC-3 .......................................3
      2.1. E-AC-3 Bit Stream ..........................................5
           2.1.1. Sync Frames and Audio Blocks ........................5
           2.1.2. Programs and Substreams .............................6
           2.1.3. Frame Sets ..........................................7
   3. RTP E-AC-3 Header Fields ........................................7
   4. RTP E-AC-3 Payload Format .......................................8
      4.1. Payload Specific Header ....................................8
      4.2. Fragmentation of E-AC-3 Frames .............................9
      4.3. Concatenation of E-AC-3 Frames .............................9
      4.4. Carriage of AC-3 Frames ...................................10
   5. Types and Names ................................................10
      5.1. Media Type Registration ...................................10
      5.2. SDP Usage .................................................13
   6. Security Considerations ........................................14
   7. Congestion Control .............................................15
   8. IANA Considerations ............................................15
   9. References .....................................................15
      9.1. Normative References ......................................15
      9.2. Informative References ....................................16

1. Introduction 🌷

so E-AC-3 [ETSI] is built on a foundation of AC-3 🏗️. it's an enhancement and extension of AC-3, which is an existing audio coding standard that's commonly used for DVD, broadcast, cable, and satellite TV content 📡. E-AC-3 is designed to run at both higher and lower data rates than AC-3, offer expanded channel configurations, and give more flexibility for carrying multiple audio program elements 🎛️. the relationship between E-AC-3 and AC-3 allows low-loss, low-cost conversion between the two, which makes E-AC-3 especially handy for apps that need to stay compatible with the existing broadcast-reception and audio/video decoding infrastructure 🙌. Dolby Digital Plus is a branded version of Enhanced AC-3 💅.

E-AC-3 has been standardized by both the European Telecommunications Standards Institute (ETSI) and the Advanced Television Systems Committee (ATSC) 🌍. it's an optional audio format for US (ATSC) and Digital Video Broadcasting (DVB) television transmission 📺. it's also a required audio format for the High Definition (HD)-DVD optical-storage media format, and it's included in the Blu-ray Disc format 💿.

there's a real need to stream E-AC-3 content over IP networks 🌐. E-AC-3 is mainly used in audio-for-video applications, so RTP is a great transport solution thanks to its mechanism for synchronizing streams 🔥. streaming E-AC-3 covers things like Internet Protocol television (IPTV), video on demand, interactive features of next generation DVD formats, and moving movies across a home network 🍿.

Section 2 gives a quick overview of the E-AC-3 algorithm ✨. Section 3 specifies values for fields in the RTP header, and Section 4 specifies the E-AC-3 payload format itself 🧩. Section 5 covers media types and Session Description Protocol (SDP) usage 📝. security considerations are in Section 6, congestion control is in Section 7, and IANA considerations are in Section 8 🔐.

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 [RFC2119] 🫶💜.

2. Overview of Enhanced-AC-3 🎼

Enhanced AC-3 (E-AC-3) is a frequency-domain perceptual audio coding system 🧠. time blocks of an audio signal get converted from the time domain to the frequency domain by a transform (the Modified Discrete Cosine Transform (MDCT)) so that a model of the human auditory perceptual system can be applied 👂. in this domain, quantization noise can be constrained to specific frequency regions 🎯. the perceptual model predicts which frequency regions the auditory system will be least able to detect quantization noise from data rate reduction in, which is honestly so clever 🤯. a more detailed technical description of E-AC-3 can be found in [2004AES] 📚.

E-AC-3 is built upon a foundation of AC-3 🧱. you can find more background on AC-3 in the AC-3 specification [ETSI], a technical paper [1994AES], and the AC-3 RTP payload format [RFC4184] 📖. the frame structure and meta-data of AC-3 are maintained 🗃️. E-AC-3 content isn't directly compatible with AC-3 decoders, but it can be converted to the AC-3 format for compatibility with existing decoders 🔄. because AC-3 is the foundation of E-AC-3, conversion between the two formats can be done in a way that minimizes the degradations associated with tandem coding 🙈. on top of that, the computational cost of the conversion is reduced compared to a full decode and re-encode 💸.

E-AC-3 takes advantage of psychoacoustic phenomena that make a big chunk of the information in a typical audio signal inaudible 👻. substantial data reduction happens by removing the inaudible information in an audio stream ✂️. source coding techniques are then used to reduce the data rate even more 🔥.

like most perceptual coders, E-AC-3 operates in the frequency domain 🌊. a 512-point MDCT transform is taken with 50% overlap, which provides 256 new frequency samples 🎀. the frequency samples are then converted to exponents and mantissas 🔢. exponents are differentially encoded 🧮. mantissas get allocated a varying number of bits depending on how audible the spectral components tied to them are 👂✨. audibility is determined via a masking curve 📈. bits for mantissas are allocated from a global bit pool 🪣.

E-AC-3 adds new coding tools, like a longer filter bank, vector quantization, and spectral extension, to give greater data efficiency and to operate at lower data rates than AC-3 🌱. going the other direction, an expanded bit stream syntax and new frame constraints permit operation at higher data rates than AC-3 🚀. the E-AC-3 syntax also allows a larger number of audio channels in one bit stream 🎚️. E-AC-3 operates at data rates from 32 kbps to 6.144 Mbps, and at three sampling rates: 32 kHz, 44.1 kHz, and 48 kHz 🎵.

E-AC-3 supports carrying multiple programs and carrying programs with more than a baseline of 5.1 audio channels 🎭. both of these extensions beyond AC-3 are accomplished by time multiplexing additional data with baseline data ⏱️. in the case of multiple programs, frames with data for the programs are interleaved 🧵. in the case of more than 5.1 channels, frames from substreams carrying the extra channels are interleaved with the independent substream that carries a 5.1-channel compatible mix 🎞️. both forms of multiplexing can occur in the same bit stream 💫. in other words, mixing multiple programs, some or all with more than 5.1 channels, is permitted 🥳.

additional channel capacity is enabled by adding substreams to a program 🌈. one primary substream, called the "independent substream", is required for each program 👑. this substream carries a self-contained mix of the audio, using a maximum of 5.1 channels, which makes its channel configuration compatible with AC-3 💖. then, additional, optional substreams can be used in the program to carry extra channels 🧁. the data for each additional channel indicates whether that channel provides data for an additional speaker location, or replacement data for one of the speaker locations already defined by a previous substream 🔊. for example, one common 7.1-channel format uses three front channels and four surround channels 🎬. it's packaged with a primary substream that contains a 5.1-channel downmix of the 7.1-channel content, using left, center, right, left surround, right surround, and low-frequency effects channels 🦋. one dependent substream supplies four channels: replacements for left surround and right surround, along with two additional surround channels (left back and right back) 💅✨.

the E-AC-3 specification [ETSI] requires that all E-AC-3 decoders be capable of decoding at least a baseline portion of any E-AC-3 bit stream 🧠. that baseline is the first independent substream of the first program, and decoders ignore the other elements of the bit stream 🙈. this baseline is limited to 5.1 channels, and a system is also able to convert to configurations with fewer channels to match its output capabilities, if needed 🔄. more capable decoders can optionally choose among and mix multiple programs, and can also decode configurations with more channels than the baseline by decoding dependent substreams 🌟.

2.1. E-AC-3 Bit Stream 🎀

2.1.1. Sync Frames and Audio Blocks 🎀

okay bestie, the basic building block of an E-AC-3 bit stream is the sync frame (we just call it a frame in this doc too) 💖 A sync frame holds everything you need to decode time domain audio samples for one or more channels over a span of one or more audio blocks, so a frame is an Application Data Unit (ADU) ✨ Each E-AC-3 frame has a Sync Information (SI) field, a Bit Stream Information (BSI) field, an Audio Frame (AF) field, and up to six audio blocks (ABs). Each AB holds 256 Pulse Code Modulation (PCM) samples for each channel. The frame wraps up with an optional auxiliary data field (AUX) and an error correction field (CRC) 🦋 Figure 1 shows the layout, where N is the number of blocks in the frame:

           +---+---+---+---------+- ... -+---------+---+---+
           |SI |BSI|AF |  AB(0)  |  ...  |  AB(N)  |AUX|CRC|
           +---+---+---+---------+- ... -+---------+---+---+

         Figure 1.  E-AC-3 frame format with more than one block

the SI field holds the info needed to acquire and maintain codec synchronization 🔥 The BSI field is where the parameters describing the coded audio service live. It carries the size of the frame in 16-bit words (frmsiz, Section E.1.3 of [ETSI]) and the sampling rate (fscod). It also carries the number of blocks in the frame (numblkscod), and the permitted values are one, two, three, or six blocks. The AF field has info about coding tools that applies to the entire frame 👑 Each block lasts 256 samples, so a frame's duration is the matching multiple of 256 samples. The time duration of the frame also depends on the sampling rate, as you can see in Table 1 🌸

  Table 1.  Time duration of E-AC-3 frame (number of blocks vs.
                            sampling rate)

+------------------+--------+-----------------+-----------------+
| blocks per frame | 32 kHz |        44.1 kHz |          48 kHz |
+------------------+--------+-----------------+-----------------+
|                1 |   8 ms |  approx. 5.8 ms |  approx. 5.3 ms |
|                2 |  16 ms | approx. 11.6 ms | approx. 10.7 ms |
|                3 |  24 ms | approx. 17.4 ms |           16 ms |
|                6 |  48 ms | approx. 34.8 ms |           32 ms |
+------------------+--------+-----------------+-----------------+

each audio block has header fields that say which coding tools are in use: block switching, dither, coupling, spectral extension, and exponent strategy 💅 Blocks can also carry metadata, which is optional and used to enhance playback (dynamic range control is one example). Last but not least, the exponents and bit allocation data needed to decode the mantissas into audio data are in there, and so are the mantissas themselves 🧚 The format of audio blocks is described in detail in [ETSI].

2.1.2. Programs and Substreams 🌈

an E-AC-3 bit stream is logically arranged into programs 💜 A bit stream can hold one or more programs, up to a max of eight. When multiple programs are in a bit stream, their frames are interleaved in time 🦋

     +----------+-     -+----------+----------+-     -+----------+-
     |Program(1)|  ...  |Program(N)|Program(1)|  ...  |Program(N)| ...
     | Frame 0  |       | Frame 0  | Frame 1  |       | Frame 1  |
     +----------+-     -+----------+----------+-     -+----------+-

   Figure 2. Interleaving of multiple programs in an E-AC-3 bit stream

each program has one independent substream and can optionally have up to eight dependent substreams 🎀 The independent substream carries a soundtrack of up to 5.1 channels (the multichannel format that matches what AC-3 can do), and it can be meaningfully decoded and presented without any of the dependent substreams attached. The dependent substreams give you alternate channel data that enable different channel configurations, like increasing the number of channels beyond 5.1 ✨ A frame of a dependent substream can be decoded by itself, but its content only makes sense to present alongside the matching independent substream. You can tell which substream a frame belongs to from parameters in the frame's BSI (strmtyp and substreamid, in Section E.1.3.1 of [ETSI]) 👑

when a program has more than one substream, the frames for those substreams are interleaved in time, and together the frames of a program that cover the same time period are called a 'program set' 🫶 Figure 3 shows how substreams are interleaved for a single program:

     / --------- program set for frame 0 ------- \
     :                                           :
   +-------------+-------------+-   -+-------------+-------------+-
   |  Program(1) |  Program(1) |     |  Program(1) |  Program(1) |
   | Independent |  Dependent  | ... |  Dependent  | Independent | ...
   |  Substream  | Substream(0)|     | Substream(n)|  Substream  |
   |   Frame 0   |   Frame 0   |     |   Frame 0   |   Frame 1   |
   +-------------+-------------+-   -+-------------+-------------+-

  Figure 3.  Interleaving of multiple substreams in an E-AC-3 program

2.1.3. Frame Sets 🍓

there's one more logical layer on the E-AC-3 bit stream, and it exists to make converting E-AC-3 bit streams into AC-3 bit streams easier 💖 Here the frames carrying six consecutive audio blocks get treated as a group called a 'frame set', no matter how many frames it takes to carry those six blocks. The grouping stretches across all programs and substreams that cover the time period of those six blocks 🌸 Since E-AC-3 frames can carry one, two, three, or six blocks, a frame set will consist of six, three, two, or one frames. AC-3 frames always carry six blocks, so the frame set is what gives you framing synchronization between an E-AC-3 bit stream and an AC-3 bit stream 🔥 The metadata that shows the alignment rides in the first frame of each frame set in an E-AC-3 stream (that first frame will be part of an independent substream). You can spot that first frame by a parameter in the BSI field: the Converter Synchronization flag (convsync, in Section E.1.3.1.34 of [ETSI]) is set to true (1) ✨

3. RTP E-AC-3 Header Fields 🦋

the RTP header is defined in the RTP specification [RFC3550] 💅 This section defines how a number of fields in that header get used.

  • Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document. It is specified by the RTP profile under which this payload format is used, or signaled dynamically out-of-band (e.g., using SDP) 🧚
  • Marker (M) bit: The M bit is set to one to indicate that the RTP packet payload contains at least one complete E-AC-3 frame or contains the final fragment of an E-AC-3 frame 💜
  • Extension (X) bit: Defined by the RTP profile used 🌈
  • Timestamp: A 32-bit word that corresponds to the sampling instant for the first E-AC-3 frame in the RTP packet. Packets containing fragments of the same frame MUST have the same timestamp. The timestamp of the first RTP packet sent SHOULD be selected at random; after that, it increases linearly according to the number of samples included in each frame. Note that the number of samples in a frame depends on the number of blocks in the frame, with 256 samples in each block. Also note that more than one frame might correspond to the same time period when multiple channel configurations or programs are present. If these frames occupy multiple packets, it is possible that the resulting packets will have the same timestamp value 😭

4. RTP E-AC-3 Payload Format 🎀

this payload format is defined for E-AC-3, as defined in Annex E of [ETSI] ✨ Heads up: E-AC-3 decoders are required to be capable of decoding AC-3 bit streams, so a receiver that can receive the E-AC-3 payload format defined in this document MUST also receive the payload format for AC-3 defined in [RFC4184] 👑

according to [RFC2736], RTP payload formats should contain an integral number of application data units (ADUs). In this payload format, the E-AC-3 frame corresponds to an ADU 🫶 Each RTP payload MUST start with the two-byte payload specific header, followed by an integral number of complete E-AC-3 frames, or a single fragment of an E-AC-3 frame 💖

if an E-AC-3 frame exceeds the MTU for a network, it SHOULD be fragmented for transmission within an RTP packet 🌸 Section 4.2 has guidelines for creating frame fragments.

4.1. Payload Specific Header 🦋

there's a two-octet Payload header at the beginning of each payload 💅 Each E-AC-3 RTP payload MUST begin with the following Payload header.

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

               Figure 4.  E-AC-3 RTP Payload header
  • Must Be Zero (MBZ): Bits marked MBZ SHALL be set to the value zero and SHALL be ignored by receivers. The bits are reserved for future extensions 🔥
  • Frame Type (F): This one-bit field indicates the type of frame(s) present in the payload. It takes the following values: 0 - One or more complete frames. 1 - Fragment of frame. (Note that the M bit in the RTP header is set for the final fragment.) 🧚
  • Number of frames/fragments (NF): An 8-bit field whose meaning depends on the Frame Type (F) in this payload. For complete frames (F of 0), it indicates the number of E-AC-3 frames in the RTP payload. For frame fragments (F of 1), it indicates 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 🌈
⚠️ When receiving E-AC-3 payloads with F = 0 and more than a single frame (NF > 1), a receiver needs to use the "frmsiz" field in the BSI header in each E-AC-3 frame to determine the frame's length, if the receiver needs to determine the boundary of the next frame. Note that the frame length varies from frame to frame in some circumstances 🙈

4.2. Fragmentation of E-AC-3 Frames 💜

the size of an E-AC-3 frame is signaled in the Frame Size (frmsiz) field in a frame's BSI header 🍓 The value of this field is one less than the number of 16-bit words in the frame. If the size of an E-AC-3 frame exceeds the MTU size, the frame SHOULD be fragmented at the RTP level. The fragmentation MAY be performed at any byte boundary in the frame. RTP packets containing fragments of the same E-AC-3 frame SHALL be sent in consecutive order, from first to last fragment, which lets a receiver assemble the fragments in the correct order ✨

4.3. Concatenation of E-AC-3 Frames 🎀

okay so sometimes E-AC-3 frames are teeny tiny, way smaller than the MTU, and it's actually smarter to stuff a few of them into one packet 📦✨

it also matters how the bit stream is organized into program sets and frame sets 🧠 if you lose a packet, you don't want that to wreck some other packet's stuff too 😭 so the vibe is: keep a complete program set or a complete frame set together in one packet 💅 and try not to mix frames from different program sets or frame sets in the same packet, unless the sets are complete. that way one dropped packet can't ruin the contents of a different packet 🫶

  • Frames from more than one program set SHOULD NOT be included in the same packet unless all program sets in the packet are complete.
  • Frames from more than one frame set SHOULD NOT be included in the same packet unless all frame sets in the packet are complete.

4.4. Carriage of AC-3 Frames 🦋

the E-AC-3 spec [ETSI] says E-AC-3 decoders have to be able to decode AC-3 frames too, which is iconic of them 👑 that same spec also lets AC-3 frames ride along inside an E-AC-3 bit stream 🌸 but because E-AC-3 and AC-3 frames aren't identical, there are rules: AC-3 frames only show up in the independent substream of the first (or only) program in an E-AC-3 bit stream 💜

and lowkey the flexibility is the best part 🌈 carrying only E-AC-3 frames, only AC-3 frames, or a mix of both are all legal setups, and you're allowed to switch between them within a bit stream ✨ the AC-3 frame format is described in [RFC4184] and specified in [ETSI] 🧚

5. Types and Names 💖

5.1. Media Type Registration 💅

this registration follows the template in [RFC4288] and goes along with [RFC3555] 📝 here's the registration itself:

To: ietf-types@iana.org
Subject: Registration of media type audio/eac3
  • Type name: audio
  • Subtype name: eac3
  • Required parameter: rate
    • the RTP timestamp clock rate, which is equal to the audio sampling rate. permitted rates are 32000, 44100, and 48000 🎵
  • Optional parameter: bitStreamConfig
    • this is the configuration of programs and substreams in the bit stream, written as a sequence of ASCII characters 🔤 it can do two jobs. first, when a session is being set up, it can help match what the bit stream needs with what the receiver can handle, so no bandwidth gets wasted on data that can't be used 🙅‍♀️ second, it tells the receiver exactly how the bit stream is configured, so if a packet goes missing, the receiver can figure out what kind of frame(s) got lost and fix things up 🛠️
    • the format is one character for each substream's type, right away followed by the number of audio channels you get when a frame of that substream (plus any other substreams it needs) is decoded 🧩 LFE channels are often called "fractional" channels (like the ".1" in 5.1), but for this parameter an LFE channel counts as one, so a 5.1-channel configuration is written as 6 🔢 the configuration of the bit stream MUST match the value of this parameter for the whole session 🔒
    • allowed substream types:
i - Independent substream.
d - Dependent substream.

the E-AC-3 spec [ETSI] decides which bit stream configurations are legal, and that limits what bitStreamConfig can look like 📜 every program starts with exactly one independent substream ('i'), and it's followed by between 0 and 8 dependent substreams ('d') that belong to that same program 👑 check out Section 2.1.2 for more on programs and substreams 🦋

for example, say a bit stream has two programs:

  • the first program has:
    • a six-channel independent substream
    • a dependent substream with the extra channels needed for eight channels
    • a second dependent substream with the further channels needed for 14 channels
  • and a second program has:
    • another six-channel independent substream
    • a dependent substream with the extra channels needed for eight channels

then the bit stream configuration is written like this:

bitStreamConfig = i6d8d14i6d8

when bitStreamConfig is used in an offer/answer exchange, a zero (0) for the channel count of a substream in an answer means "I don't want this substream" 🙅‍♀️

Encoding considerations:

this media type is framed and contains binary data 📦

Security considerations:

See Section 6 of RFC 4598.

Interoperability considerations:

to stay interoperable with AC-3-capable endpoints, when negotiation is possible, an E-AC-3 endpoint SHOULD also declare itself as AC-3 capable (so it supports "audio/ac3" too, as specified in RFC 4184 [RFC4184]) 🫶 and yes, every E-AC-3 endpoint is required to be AC-3 capable 💖

Published specification:

RFC 4598 and ETSI TS 102.366 [ETSI] 📚

Applications that use this media type:

multichannel audio compression, and audio for video 🎬

Additional information:

  • Magic number(s): the first two octets of every E-AC-3 frame are always the synchronization word, which has the hex value 0x0B77 🔍

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 RTP [RFC3550] 🌸 transport inside other framing protocols isn't 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 media type spec maps onto fields in the Session Description Protocol (SDP) [RFC2327], which is what people usually use to describe RTP sessions 🧚 when SDP is used to set up E-AC-3 sessions, here's how it maps:

  • The media type ("audio") goes in the SDP "m=" line as the media name.
  • The media subtype ("eac3") goes in the SDP "a=rtpmap" line as the encoding name.
  • The required parameter "rate" also goes in "a=rtpmap" as the clock rate. (The optional "channels" rtpmap encoding parameter isn't used. the info goes in bitStreamConfig instead 💅)
  • The optional parameter "bitStreamConfig" goes in the SDP "a=fmtp" attribute.

here's an example of SDP data for E-AC-3:

m=audio 49111 RTP/AVP 100
a=rtpmap:100 eac3/48000
a=fmtp:100 bitStreamConfig i6d8d14i6d8

there are some things to keep in mind when SDP is used for offer/answer exchanges [RFC3264] 🔥

  • The "rate" is a symmetric parameter, so the answer MUST use the same value, or the answerer removes the payload type. 🚫
  • The "bitStreamConfig" parameter is declarative. for sendonly, it says the intended substream arrangement and channel configuration to transmit. for recvonly or sendrecv, it says the desired arrangement and channel configuration to receive 🎧 the format of the bitStreamConfig value in an answer MAY differ from the offer by swapping the channel count of any unwanted substream for '0'. it's totally valid to zero out dependent substreams with channel configurations you don't want, and to zero out every substream of an unwanted program. then the sender MAY reoffer the stream in the receiver's preferred configuration, if it can actually provide that. 💫 and here's the tea: all receivers can receive, and all decoders can decode, any legal bit stream configuration, so this parameter exchange isn't needed for interoperability 🍓 it might just help optimize sending, so the receiver gets the number of programs or channels it asked for ✨
  • an AC-3 bit stream is a special case of an E-AC-3 bit stream, so it's allowed to be carried in the E-AC-3 payload format. but to keep things working with receivers that support the AC-3 payload format but not the E-AC-3 one, a sender that wants to send an AC-3 bit stream in the E-AC-3 payload format SHOULD also offer the session in the AC-3 payload format, by including payload types for both media subtypes: 'ac3' and 'eac3' 🫶

6. Security Considerations 🔐

the payload format in this document is subject to the security considerations in RTP [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 🤐 and to protect against modification by intermediate entities and make sure the stream is authentic, integrity protection and authentication would be required 🚨 all three (confidentiality, integrity protection, and authentication) have to be handled by a mechanism outside this payload format, for example Secure Real-time Transport Protocol (SRTP) [RFC3711] 💀

the E-AC-3 format is designed so decoders can determine whether a data frame is valid. the required decoder response to a malformed frame is to discard the malformed data and conceal 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 in response to errors or attacks 🛑

7. Congestion Control 🚦

7. Congestion Control 🚦

the general congestion control considerations for transporting RTP data also apply to E-AC-3 audio over RTP; see RTP [RFC3550] and any applicable RTP profile (e.g., [RFC3551]) 🌊

E-AC-3 is a variable bit rate coding system, so there are lots of techniques you can use to adapt to network bandwidth 🦋

8. IANA Considerations 🌈

IANA has registered a new media subtype for E-AC-3 (see Section 5) 🎀

9. References 📚

9.1. Normative References 🔖

  • [ETSI] ETSI, "Digital Audio Compression (AC-3, Enhanced AC-3) Standard", TS 102 366, February 2005.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC4184] Link, B., Hager, T., and J. Flaks, "RTP Payload Format for AC-3 Audio", RFC 4184, October 2005.
  • [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
  • [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
  • [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
  • [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
  • [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

9.2. Informative References ✨

okay bestie, these are the "go read this if you're curious" sources 📚 and they're all legit:

  • [2004AES] Fielder, L., Andersen, R., Crockett, B., Davidson, G., Davis, M., Turner, S., Vinton, M., and P. Williams, "Introduction to Dolby Digital Plus, an Enhancement to the Dolby Digital Coding System", Preprint 6196, Presented at the 117th Convention of the Audio Engineering Society, October 2004. 🎧
  • [1994AES] Todd, C., Davidson, G., Davis, M., Fielder, L., Link, B., and S. Vernon, "AC-3: Flexible Perceptual Coding for Audio Transmission and Storage", Preprint 3796, Presented at the 96th Convention of the Audio Engineering Society, May 1994. 🦋
  • [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. 🎀
  • [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. 🔐

Author's Address 💌

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

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

Copyright (C) The Internet Society (2006). 💜

okay so this document is covered by the rights, licenses and restrictions in BCP 78, and apart from what that says, the authors keep all of their rights. 🙃

The document and the info in it are handed over "AS IS". The contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all say no to every warranty, express or implied. That includes no promise that using the info won't infringe anyone's rights, and no implied promise of merchantability or fitness for a particular purpose. 💀

Intellectual Property 🔒

The IETF doesn't take a side on whether any Intellectual Property Rights (or other rights) that someone might claim over the tech in this document are valid, how far they reach, or whether you can get a license for them. It also doesn't say it has searched for those rights itself. If you want the details on how rights work for RFC documents, check BCP 78 and BCP 79. 📖

Any IPR disclosures sent to the IETF Secretariat, along with any promised licenses, or the results of trying to get a general license or permission for implementers or users to use those proprietary rights, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. 🗂️

The IETF also invites anyone to tell it about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that to the IETF at ietf-ipr@ietf.org. 🫶

Acknowledgement 🌈

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). 💖

📦 where this page comes from