Internet Engineering Task Force
Jason Flaks
Internet Draft Dolby Laboratories
Document: draft-flaks-avt-rtp-ac3-00.txt November 2001
Expires: May 2002

RTP Payload Format for AC-3 Streams

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMEDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].

Abstract

This document describes an RTP payload format for transporting AC-3
encoded audio data. AC-3 is a high quality multichannel audio coding
system fully described in [2] by the Advanced Television Standards
Committee (ATSC). The RTP payload format presented in this document
provides mechanisms for interleaving redundant data, which can increase
packet loss resilience. An intelligent method for fragmenting AC-3
frames that exceed the maximum transfer unit (MTU) is also described.

1. Introduction

AC-3 is a high quality audio codec designed to encode multiple channels
of audio into a low bit-rate format. AC-3 achieves its large
compression ratios via encoding a multiplicity of channels as a single
entity. Dolby digital, which is a branded version of AC-3 encodes up to
5.1 channels of audio.

AC-3 has been adopted as an audio compression scheme for many consumer
and professional applications. AC-3 is the mandatory codec for DVD-
video, ATSC digital terrestrial television, laser disc, and DVD-audio
(as an optional multichannel audio format). AC-3 is also a common audio
format for film.

Presently there exists a tremendous amount of content encoded in AC-3.
The majority of AC-3 content is comprised of more then two channels. It
is highly likely that people may wish to stream AC-3 data over computer
networks. Applications for streaming AC-3 range from video on demand to
multichannel Internet radio. RTP provides a mechanism for stream
synchronization and hence serves as the best transport solution for AC-
3, which is a codec primarily used in audio for video applications. The
RTP payload described in this document also provides a method of
ensuring a continuous high quality AC-3 stream.

1.1 Overview of AC-3

AC-3 can deliver upwards of 5.1 channels of audio at data rates
approximately equal to half of one PCM channel [2], [3], [4]. The ".1"
refers to a band limited optional low-frequency enhancement channel.
AC-3 was designed for signals sampled at rates of 32, 44.1, or 48 kHz.
Data rates can vary between 64 kbps and 640 kpbs depending the number of
channels and desired quality.

AC-3 exploits psychoacoustic phenomenon that reveal large amounts of
inaudible information contained in a typical audio signal. Substantial
data reduction occurs via the removal of all inaudible information
contained in an audio stream. Source coding techniques are further used
to reduce the data used to code an audio signal.

Like most perceptual coders, AC-3 operates in the frequency domain. A
512-point TDAC transform is take with 50% overlap, providing 256 new
frequency samples. Frequency samples are then converted to exponents
and mantissas. Exponents are differentially encoded. Mantissas are
allocated a varying number of bits depending on the audibility of the
spectral component associated with it. Audibility is determined via a
masking curve. Bits for mantissas are allocated from a global bit pool.

1.2 AC-3 Bitstream

AC-3 bitstreams are organized into synchronization frames. Each AC-3
sync frame contains a Sync Information (SI) field, a Bit Stream
Information (BSI) field, and 6 audio blocks (AB) representing 256 PCM
samples for each channel. The entire frame represents a time duration
of 1536 PCM samples across all coded channels (32 msec @ 48kHz) [2].
Figure 1 shows the AC-3 frame format.

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

The Synchronization Information field contains information needed to
acquire and maintain synchronization. The Bit Stream Information field
contains parameters that describe the coded audio service [2]. Each
audio block also contains fields that determine the usage of block
switching, dither, dynamic range control, coupling, and exponent
strategy. Figure 2 shows the format of an AC-3 audio block

2. RTP AC-3 Payload Format

According to [5] RTP payload formats should contain an integral number
of application data units (ADUs). With compression algorithms an ADU
typically coincides with codec frame boundaries. In this case an ADU is
equivalent to an AC-3 sync frame. Hence each RTP packet will contain an
integral number of AC-3 frames unless the AC-3 frame exceeds the maximum
transfer unit (MTU) of the underlying network.

RTP_Payload = x * AC-3_Frame,
Where x belongs to |Z| (set of all positive integers),
and RTP_Payload < MTU

2.1 RTP Header Extension

The following header extension should be at the front of every AC-3 RTP
payload. The fields should aid in maintaining order when multiple AC-3
frames are sent in a single payload, or when an AC-3 is fragmented over
several frames. A field is also defined to indicate the addition of
redundant data.

0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|NF | FS |R|RSV|
+-+-+-+-+-+-+-+-+

Number of frames (NF): Number of AC-3 frames present in the RTP payload.
This should be set to 0 if the frame is fragmented.

Fragment sequence number (FS): This number indicates the sequence number
of the fragment contained in this RTP payload.

Redundant Data Bit (R): This bit is set to 1 if the packet contains
redundant data for correcting possible lost or corrupted data.

Reserved (RSV): This field is reserved for a later date.

Figure 4 shows how a full AC-3 RTP payload format should appear.

0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NF | FS |R|RSV| AC-3 Frame(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC-3 Frame(N) | Redundant Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2 Fragmentation of AC-3 Frames

The size of AC-3 frames are consistent throughout an encode procedure of
a particular piece of audio, but the initial frame size selected can be
chosen from large number of possibilities. According to table 5.13 in
[2] frames sizes range from 128 bytes to 3840 bytes dependent upon the
initial desired bit rate and the sample rate of the uncompressed audio.

AC-3 frame sizes can be quite large, which may require fragmentation.
For example an audio file sampled at 32 kHz and compressed with a
desired bit rate of 640 kbps would have a frame size of 3840 bytes.
This exceeds the standard 1500 byte MTU of an Ethernet network, and
would require fragmentation. In [6] it is specified that fragmentation
should not be left to IP layer, but instead should be handled by the
application itself.

AC-3 frames were designed with possibility of buffers being smaller then
an entire AC-3 frame. For this reason each AC-3 frame contains two 16-
bit CRC words. CRC1 is contained in the synchronization information
(SI) header located at the beginning of each AC-3 frame. CRC1 is the
second 16-bit word of the frame. Figure 2 shows the structure of the SI
header.

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SYNC WORD | CRC1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FSC|FRMSIZECD |
+-+-+-+-+-+-+-+-+

CRC2 is the last 16-bit word of an AC-3 frame. CRC1 applies to the
first 5/8ths of the frame excluding the sync word. CRC2 covers the
remaining 3/8ths of the frame as well as the entire frame (excluding th e
sync word). All AC-3 encoders enforce specific block size restrictions
that guarantee blocks 0 and 1 are completely covered by CRC1 [2]. This
allows decoders to immediately begin processing block 0 when the 5/8ths
point is reached.

This 5/8ths split in all AC-3 frames, which was intended for the
possibility of smaller input buffers, provides a very logical
fragmentation unit. Using the 5/8ths point provides two gains:

1) A CRC check can be done on the beginning of the frame
providing early detection of a corrupted data
2) Presuming the remaining date in the frame arrives in a
timely fashion, immediate processing can be performed on
block 0 of the AC-3 frame decreasing any delays in having to
concatenate the frame before sending it to the decoder.

In [2] the 5/8ths point is defined to be:

5/8-framesize = truncate(framesize/2) + truncate(framesize/8)

According to table 7.34 in [2], 5/8ths frame sizes can range from 80
bytes to 2400 bytes. Hence there are still instances where the 5/8ths
boundary may exceed the MTU of the underlying network. In an Ethernet
network this would be rare because the majority of AC-3 data publicly
available is sampled at 48kHz and is encoded at a data rate of 384kbps
or 448kbps. This provides a 5/8ths point of 960 bytes and 1120 bytes
respectively, which would be less then the MTU of a typical Ethernet
network. In the rare instances where even the 5/8ths point exceeds the
MTU, AC-3 frames should be arbitrarily fragmented to a length that is
less the MTU.

2.3 Data Resiliency

In a previously defined AC-3 RTP payload format a method for data
resiliency is presented. The paper suggests that AC-3 frames encoded at
32 kbps should be interleaved with the higher quality AC-3 frames,
allowing the AC-3 decoder to decode the lower quality frame if the high
quality packet is dropped, lost, or arrives with errors.

The method described above is a suitable method for trying to send
redundant data. However it may be bandwidth intensive and the redundant
data can be extremely low quality, especially in cases where a large
number of channels are used.

AC-3 data is often used for film audio. The audio track is stored
between the sprocket holes of the film. Over time wear can render
sections of the AC-3 track unreadable. When no other error corrections
techniques can recover the lost data the two-channel audio track will be
used in its place. We present a similar method here for multichannel
audio.

When encoding multichannel audio a secondary two-channel version of the
audio can also be encoded at a lower bit rate. Since the audio is
reduced to two channels, it is still possible to maintain high quality
even at a lower bit rate. The lower bit-rate two-channel version can be
interleaved with the multichannel audio, and when a packet is lost or
corrupted the two-channel version can be used in its place. The
redundant data shall be interleaved such that for some RTP_Packet(N)
with Multichannel AC-3 Frame(M), then RTP_Packet(N-1) will contain the
two-channel AC-3 Frame(M). Figure 5 shows how redundant data should be
interleaved

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RTP(N-1):| Multichannel AC-3 Frame(M-1)| Two-channel AC-3 Frame(M) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RTP(N):| Multichannel AC-3 Frame(M)| Two-channel AC-3 Frame(M+1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Continuously sending redundant data can unnecessarily increase the
bandwidth. Therefore in certain instances one may wish to send this
redundant data when it is absolutely necessary. One example may be to
only send the redundant data when a transient is involved. This would
require a transient detector before the encode process.

3 RTP header fields

Payload Type (PT): It is expected that the RTP profile for a particular
class of applications will assign a payload type for this encoding, or
alternatively a payload type in the dynamic range [96,127] shall be
chosen.

Marker (M) bit: The M bit is set for last fragment of an AC-3 frame.
In instances where one or more full AC-3 frames is encapsulated in an
RTP packet the M bit will be set, and the full frame itself will be
considered the last fragment.

Extension (X) bit: Defined by the RTP profile used.

Timestamp: A 32-bit word that corresponds to the sampling instant for
the first AC-3 frame in an RTP packet. AC-3 encodes data sampled at
32kHz, 44.1kHz, and 48kHz. Fragmented frames shall maintain the same
time stamp until the last fragment is sent. The starting timestamp is
selected at random.

4 Types and Names

4.1 MIME type registration

MIME media type name: audio
MIME subtype name: ac3

Required parameters: none
Optional parameters: channels, ptime, maxptime

Encoding considerations:
The AC-3 bitstream shall be generated according to the AC-3
specification [2]. This bitstream is binary data and MUST be encoded
for non-binary transport (for Email or any transport that cannot
accommodate binary directly, the Base64 encoding is sufficient). This
type is also defined for transfer via RTP. All RTP packets MUST be
packetized using the RTP payload format described in this document.

Security considerations: see section 5 of this document

Interoperability considerations: none

Published specification: see [2]

Applications:
Multichannel audio compression for audio and audio for video

Additional Information: none

Magic number(s): none
File extension(s): .ac3
Macintosh File Type Code(s): none
Object Identifier(s) or OID(s): none

Personal information: Jason Flaks
Email: jsf@dolby.com

Intended Usage: COMMON

Author/Change controller: Author: jsf@dolby.com
Change Controller: IETF AVT WG

4.2 SDP usage

The encoding name when using SDP [6] SHALL be "ac3" (MIME subtype). An
example of the media representation in SDP is given below.

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

5. Security considerations

In order to protect copyrighted material, certain security precautions
may be necessary. The payload format described in this document is
subject to the security considerations defined in the RTP specification
[7]. The security considerations discussed in [7] imply the usage of
encryption to protect the confidentiality of content. Such an
encryption scheme is harmless to the encoded audio data presuming the
data is decrypted before being sent to the decoder.

6. References

[1] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
Levels", RFC 2119, Internet Engineering Task Force, March 1997.

[2] U.S. Advanced Television Systems Committee (ATSC), "Digital Audio
Compression (AC-3) Standard," Doc A/52, December 1995.

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

[4] 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.

[5] Handley, M. and Perkins, C., "Guidelines for Writers of RTP Payload
Format Specifications," RFC 2736, Internet Engineering Task Force,
December 1999.

[6] Handley, M. and Jacobson, V., "SDP: Session Description Protocol,"
RFC 2327, Internet Engineering Task Force, April 1998

[7] Schulzrinne, Casner, Frederick, and Jacobson, "RTP: A Transport
Protocol for Real-Time Applications," RFC 1889, Internet Engineering
Task Force, February 1996.

7. Authors' Addresses

Jason Flaks
Dolby Laboratories
100 Potrero Ave
San Francisco, CA 94103
Email: jsf@dolby.com
www.dolby.com