RTP Payload Format for AC-3 Audio
Extracted elements (21)
Packing multiple AC-3 frames into each RTP payload reduces the number of packets sent and hence the overhead from IP/UDP/RTP headers, at the expense of increased delay and reduced robustness against packet losses. This trade-off is available because AC-3 encoders support a range of bit rates.
RTP was selected as the transport for AC-3 because it provides stream synchronization, which is essential for AC-3 used primarily in audio-for-video applications such as movie streaming, video on demand, and multichannel Internet radio.
When fragmenting an AC-3 frame, the first fragment MAY be sized to contain at least the first 5/8ths of the frame. This portion is guaranteed to contain data necessary to decode the first two audio blocks, providing greater resilience to packet loss even before the complete frame is received.
The channel order used in AC-3 differs from the channel order scheme defined in RFC 3551. Implementers must use the AC-3 channel order scheme found in Table 5.8 of the ATSC standard rather than the RFC 3551 scheme.
When an RTP payload contains multiple complete AC-3 frames (FT=0, NF>1), the receiver must use the 'frmsizecod' field in the Synchronization Information block of each frame to determine frame boundaries, since frame length may vary from frame to frame.
Each RTP payload MUST start with the two-byte payload header followed by either an integral number of complete AC-3 frames or by a single fragment of an AC-3 frame.
If an AC-3 frame exceeds the network MTU, it SHOULD be fragmented at the RTP level. RTP packets containing fragments of the same frame SHALL be sent in consecutive order from first to last fragment.
In SDP offer/answer exchanges, the 'rate' parameter is symmetric and the answer MUST use the same value or remove the payload type.
RTP packets containing fragments of the same AC-3 frame MUST carry the same timestamp. The timestamp of the first RTP packet sent SHOULD be selected at random; thereafter it increases by 1536 per frame.
The 'channels' media type parameter MUST be a number between 1 and 6. The LFE ('.1') channel MUST be counted as one channel.
The NF field MUST be identical for all RTP packets containing fragments of the same AC-3 frame, indicating the total number of fragments making up that frame.
The RTP M (marker) bit is set to one to indicate that the RTP packet payload contains at least one complete AC-3 frame or contains the final fragment of an AC-3 frame.
This payload format MUST NOT be used to carry E-AC-3 (as defined in Annex E of ATSC); it is defined only for AC-3 as specified in the main part and Annex D of the ATSC standard.
An AC-3 synchronization frame contains a Synchronization Information (SI) field, a Bit Stream Information (BSI) field, six audio blocks (AB0–AB5) each representing 256 PCM samples, an optional auxiliary data field (AUX), and an error correction field (CRC). The entire frame represents 1536 PCM samples across all coded channels.
Each AC-3 audio block contains Block Switch flags, Dither Flags, Dynamic Range Control, Coupling Strategy, Coupling Coordinates, Exponent Strategy, Exponents, Bit Allocation Parameters, and Mantissas. Field sizes vary depending on the coded data.
SDP mapping for AC-3: media type 'audio' in 'm=', subtype 'ac3' in 'a=rtpmap' as encoding name, 'rate' as clock rate optionally followed by channel count, and 'ptime'/'maxptime' in respective SDP attributes. Example: 'a=rtpmap:100 ac3/48000/6'.
The audio/ac3 media type requires the 'rate' parameter (RTP timestamp clock rate equal to sampling rate: 32000, 44100, or 48000 Hz) and accepts optional parameters 'channels' (1–6), 'ptime', and 'maxptime'. The media type is defined only for transfer via RTP.
A new MIME media subtype 'audio/ac3' has been registered with IANA. Required parameter: 'rate' (32000, 44100, or 48000 Hz). Optional parameters: 'channels' (1–6), 'ptime', 'maxptime'. Transfer is defined only via RTP.
AC-3 decoders are designed to detect malformed frames and discard them, concealing errors in audio output until a valid frame is decoded. This error-resilience design is expected to prevent crashes and abnormal decoder behavior in response to malformed data or attacks.
Confidentiality, integrity protection, and authentication are not provided by this payload format and must be supplied externally, e.g., via SRTP (RFC 3711), to protect user privacy and copyrighted material and to prevent modification by intermediate entities.
The two-octet AC-3 RTP payload header contains a 6-bit MBZ (Must Be Zero) field, a 2-bit FT (Frame Type) field, and an 8-bit NF (Number of Frames/Fragments) field. FT encodes four values: 0=complete frames, 1=initial fragment including first 5/8ths, 2=initial fragment not including first 5/8ths, 3=non-initial fragment.