Real-time Audio/Video Decoders for Digital

Multimedia Broadcasting
Victor H. S. Ha, Sung-Kyu Choi, Jong-Gu Jeon, Geon-Hyoung Lee, Won-Kap Jang, and Woo-Sung Shim
Samsung Electronics Co., Ltd.
Digital Media R&D Center, Suwon, Korea
Tel: +82-31-200-3028, Fax: +82-31-200-3147
jgjeon@samsung.com

Abstract— A new national standard for Digital Multimedia
Broadcasting (DMB) has been drafted in Korea to provide
high quality digital audio, video, and data broadcasting services
to fixed, mobile, and portable receivers. We have developed
the world’s first DSP/FPGA implementation of the portable
DMB receiver, complete with an RF receiver, a 6.4-inch LCD
display, and audio/video/data decoders. In this paper, we present
the design, implementation, and performance of this portable
DMB receiver. First, we provide a brief overview of the DMB
system and the audio/video coding tools supported by it, i.e.,
MPEG-4 BSAC and MPEG-4 Part 10 AVC/H.264. We discuss
the low-power high-performance design of the DMB receiver,
focusing particularly on the audio/video decoding parts. Finally,
we illustrate the performance of the portable DMB receiver that
operates in real-time at the overall frequency of 25 MHz.
I. I NTRODUCTION
In Korea, a new national standard for terrestrial Digital
Multimedia Broadcasting (DMB) has been developed [1].
The Korean DMB system adopts as its base the European
Digital Audio Broadcasting (DAB) system known as Eureka-
147 [2]. The DMB system adds to Eureka-147 various coding,
networking, and error correcting tools to process multimedia
contents at the overall bit error rate (BER) of 10−9 . The DMB
service is expected to provide high-quality digital broadcasting
services to fixed, mobile, and portable receivers with a nation-
wide coverage.
In this paper, we introduce the portable receiver for terres-
trial DMB with an emphasis on the audio and video decoder
parts. The audio coding in DMB is performed using the
MPEG-4 BSAC audio codec [3]. BSAC builds upon MPEG-4
AAC (Advanced Audio Coding) to provide fine grain bitstream
scalability and error resilience. The video coding in DMB is
based on the newest international standard known as MPEG-
4 Part 10 AVC/H.264 [4]. This new video coding standard
improves coding efficiency over other existing standards such
as MPEG-2 and MPEG-4 Advanced Simple Profile (ASP).
H.264 has a large set of applications ranging from low bit-
rate conversational services to high definition (HD) digital
video broadcasting. The implementation of BSAC and H.264
in the portable DMB receiver raises a number of design
issues such as portability, low power consumption, and high
performance. In this paper, we focus on these issues and
present our solutions in the design and implementation of the
DMB receiver.
The paper is organized as follows. In section II, we give a
brief overview of the Korean DMB system, MPEG-4 BSAC
audio coding standard, and H.264 video coding standard. In
sections III and IV, we discuss the design and implementation
of the audio and video decoders for DMB, respectively. In
section V, we present the performance of the DMB receiver
based on our DSP/FPGA implementation. Section VI summa-
rizes the paper.
II. AUDIO AND V IDEO C ODING IN DMB
This section provides a brief overview of the Korean DMB
system, MPEG-4 BSAC audio coding standard, and H.264
video coding standard. Readers are referred to [5] [6] [7] [8]
and references therein for further information on BSAC, H.264
and DMB.
A. Digital Multimedia Broadcasting in Korea
DMB is the next generation digital broadcasting service
for indoor and outdoor users. The DMB users can enjoy
CD-quality stereo audio services and real-time video/data
streaming services anywhere in the nation while moving at
the speed of up to 200 km/h. The Korean DMB system
is based on Eureka-147, the European DAB system. To
support multimedia contents, the DMB standard incorporates
various networking and error correcting tools such as the
Reed Solomon (RS) coding, MPEG-2 Transport Stream (TS)
packets, MPEG-2 PES packets, and MPEG-4 SL packets.
Multimedia contents are processed by the following set of
codecs:
• Video : MPEG-4 AVC (ISO/IEC 14496-10) / H.264
• Audio : MPEG-4 (ISO/IEC 14496-3) BSAC
• Data : MPEG-4 (ISO/IEC 14496-1) Core2D @ Level 1
In this paper, we focus on the design and implementation of
the audio and video decoders.
B. BSAC Audio Coding Standard
BSAC is a part of the newest audio coding standard from
ISO/IEC known as ISO/IEC 14496-3 or MPEG-4 Audio.
BSAC is mainly based on MPEG-4 AAC and uses most of its
tools. BSAC improves upon MPEG-4 AAC by offering a fine
grain bitstream scalability and error resilience. Its compression
rate is comparable to the AAC Main profile.

Proceedings of the 4th IEEE International Workshop on System-on-Chip for Real-Time Applications (IWSOC’04)
0-7695-2182-7/04 $ 20.00 IEEE
Authorized licensed use limited to: Pusan National University Library. Downloaded on December 7, 2009 at 23:36 from IEEE Xplore. Restrictions apply.

Fig. 1. Bit-Slicing in BSAC
1) BSAC Features: MPEG-4 BSAC uses the same set of
tools as MPEG-4 AAC including 1024/128 point MDCT
(Modified Discrete Cosine Transform), Noiseless coding, Long
Term Prediction, etc. The main features of BSAC are (a) fine
grain bitstream scalability (b) efficient audio compression, and
(c) error resilience.
The scalable coder achieves audio coding at different bit-
rates and qualities by processing the bitstream in an ordered
set of layers. The base layer is the smallest sub-set of the
bitstream that can be decoded independently to generate the
audio output. The remaining bitstream is organized into a
number of enhancement layers such that each enhancement
layer improves the audio quality. BSAC supports a wide
range of bit-rates from the low bit-rate stream of 16 kbps
per channel (kbps/ch) at the base layer to the higher bit-rate
stream of 64 kbps/ch at the top layer. BSAC offers a fine grain
bitstream scalability at 1 kbps/ch. This fine grain scalability
of BSAC comes from the bit-sliced coding technique. In bit-
sliced coding, the quantized spectral values are first grouped by
the frequency bands. Then, the bits in each group are processed
in slices, i.e., “bit-sliced”, in the order from MSB (most
significant bits) to LSB (least significant bits). See Figure 1.
The most significant bits across the groups form the first bit-
slice. This bit-slice is fed into the noiseless coding part and
then transmitted in the base layer. The next significant bits
form the second bit-slice, which is processed and transmitted
in the first enhancement layer. This process continues until the
least significant bits are processed and transmitted in the top
enhancement layer. Each enhancement layer adds 1 kbps/ch
of bitstream and thus provides fine grain scalability in BSAC.
The bit-slices that are fed into the noiseless coding part
go through an entropy coding process. In BSAC, the entropy
coding is carried out by an arithmetic coder. In AAC, a
Huffman coder is used instead. The arithmetic coder in BSAC
enhances the coding efficiency of the bit-sliced audio streams.
The Error resilience feature of BSAC is implemented by
SBA (Segmented Binary Arithmetic coding). In SBA, multiple
layers of audio streams are grouped again into segments.
Any error propagation is constrained to a single segment in
BSAC by re-initializing the arithmetic coder after every N th
enhancement layer.
Proceedings of the 4th IEEE International Workshop on System-on-Chip for Real-Time Applications (IWSOC’04)
0-7695-2182-7/04 $ 20.00 IEEE
Authorized licensed use limited to: Pusan National University Library. Downloaded on December 7, 2009 at 23:36 from IEEE Xplore. Restrictions apply.
2) BSAC in DMB: The audio service in DMB should sup-
port the standardized stereo audio broadcasting at the sampling
rates of 24, 44.1, or 48 KHz. The service should provide CD-
quality audio for the audio-only broadcasting and better than
the analog FM radio quality for the audio accompanying the
video. The maximum bit-rate for the audio data in stereo is
set to 128 Kbps.
DMB employs the MPEG-4 BSAC standard’s LC profile
that is suitable for mobile applications. BSAC allows adap-
tive bit-rate control, a smaller initial buffer, and a seamless
play of digital audio. In BSAC for DMB, the prediction
and long-term prediction tools are not used. The variable
epConfig is set to zero in AudioSpecificConfig(). Variables
frameLengthFlag and DependOnCoreCoder are set to zero in
GASpecificConfig(). The error resilience tool is not supported
to lower the implementation complexity, i.e., sba mode is set
to zero in bsac header(). ltp data present is set to zero in
general header().
C. H.264 Video Coding Standard
MPEG-4 Part 10 AVC/H.264 is the state-of-the-art interna-
tional video coding standard developed by Joint Video Team
(JVT) consisting of experts from ITU-T’s Video Coding Ex-
perts Group (VCEG) and ISO/IEC’s Moving Picture Experts
Group (MPEG). The new standard has recently been approved
by ITU-T as Recommendation H.264 and by ISO/IEC as
International Standard 14496-10 (MPEG-4 part 10) Advanced
Video Coding (AVC). H.264 is composed of two main parts:
(i) Video Coding Layer(VCL) that efficiently represents the
video contents and (ii) Network Abstraction Layer (NAL) that
provides network friendliness. H.264 significantly improves
coding efficiency over prior video coding standards. For exam-
ple, it is established that H.264 improves the coding efficiency
over MPEG-2 by a factor of 2 at the same video quality. The
cost is an increased complexity.
1) H.264 Features: In H.264, the overall gain in coding effi-
ciency results from a plurality of small improvements in Video
Coding Layer (VCL). The important improvements in VCL are
(a) enhanced motion-prediction, (b) 4×4 integer transform, (c)
adaptive deblocking filter, and (d) enhanced entropy coding.
The H.264 video codec enhances the motion-prediction by
employing a new set of techniques such as variable block-size
motion compensation, quarter-sample-accurate motion vectors,
multiple reference pictures, and spatial prediction for intra
coded pictures. Due to these highly sophisticated prediction
techniques, the transform coding in H.264 is simplified to
a 4 × 4 integer transform. This new transform is closely
related to the Discrete Cosine Transform (DCT) but is imple-
mented with 16-bit integer arithmetic operations. The condi-
tional application of a deblocking filter removes the artifacts
across block boundaries and improves the visual quality of
decoded pictures. Finally, the entropy coding is improved by
introducing new context adaptive entropy coding tools such
as Context Adaptive Variable Length Coding (CAVLC) and
Context Adaptive Binary Arithmetic Coding (CABAC).
 The goal of Network Abstraction Layer (NAL) is to pro-
vide “network friendliness” by formatting video contents and
appending appropriate header information for the transport
and storage of VCL processed video data. There are a
number of highlighted features of NAL. The parameter set
structure separates handling of important but infrequently
changing information such as sequence parameter sets and
picture parameter sets for robust and efficient conveyance of
header information. NAL units provide a generic format for
use in both packet-oriented and bitstream-oriented transport
systems. Flexible slice sizes allow customized packaging of
compressed video data appropriate for each specific network.
A slice in H.264 is the smallest unit that can be encoded or
decoded independently. A picture is composed of one or more
slices. Other NAL-related techniques that provide robustness
to data errors and losses include Flexible Macroblock Ordering
(FMO), Arbitrary Slice Ordering (ASO), Redundant Pictures
(RP), Slice Data Partitioning, and SP/SI pictures.
Both VCL and NAL of the H.264 video coding standard
offer a wide selection of tools for the compression and
transmission of video contents. Clearly, not all of these tools
are needed in every implementation of H.264-based video
coding systems. To deal with this issue, the notions of profiles
and levels are introduced. Profiles specify a set of application-
dependent algorithmic features to be supported by decoders.
Levels set limits on performance-related parameter values
(maximum picture size, frame rate, etc.) corresponding to
the processing and memory capabilities of video coders and
decoders.
2) H.264 in DMB: The DMB standard specifies the video
service to be provided with a maximum display dimension of
352 × 288 pixels at the frame rate of 30 frames per second
(fps). It should deliver a VCD-quality video on a 7-inch LCD
display, allow a random access at 0.5-second random access
intervals, and resume playing the video sequence without
skipping after a 5-second long pause.
The DMB video decoder supports H.264 Baseline profile
at Level 1.3. However, the video decoder is not required to
support FMO, ASO, and RP capabilities. The DMB video
decoder also respects the following set of constraints. First,
the decoder supports a variety of display formats such as
QCIF, QVGA, WDF, and CIF. In the picture parameter set, the
number of slice group is set to 1 (num slice groups minus1
= 0) and the redundant picture count is set to zero (redun-
dant pic cnt present flag = 0). In the sequence parameter set,
the picture order count type is set to 2 (pic order cnt type
= 2) and the number of reference pictures is limited to 3
(num ref frames = 3). The range of vertical component of mo-
tion vectors (maxVmvR) is set to [−64, 63.75]. The maximum
size of the decoded picture buffer (maxDPB) is constrained
to 445.5 Kbytes. To allow the random access interval of 0.5
seconds, an IDR (Instantaneous Decoding Refresh) picture is
inserted in the sequence every 0.5 seconds.
Proceedings of the 4th IEEE International Workshop on System-on-Chip for Real-Time Applications (IWSOC’04)
0-7695-2182-7/04 $ 20.00 IEEE
Authorized licensed use limited to: Pusan National University Library. Downloaded on December 7, 2009 at 23:36 from IEEE Xplore. Restrictions apply.
Fig. 2. Block Diagram of BSAC decoder
III. AUDIO D ECODER
In this section, we discuss the design and implementation
of the real-time audio decoder based on MPEG-4 BSAC.
We implemented the audio decoder using Teaklite DSP and
an FPGA. Teaklite is the 16-bit processor with a low power
consumption level and is suitable for the development of mo-
bile devices. To improve the decoding time, we implemented
IMDCT as a hardware module in an FPGA. The components
of the BSAC decoder are shown in Figure 2. The Teaklite DSP
core implements most of the audio decoder functions and is
equipped with X-memory, Y-memory, and Program-memory
connected to the core by X-, Y-, and P-buses, respectively. The
IMDCT module is implemented in an FPGA with Z-memory
connected to the Teaklite core by the Z-bus. The system bus
connects the audio decoder to the ARM processor, SDRAMs,
and the audio controller.
The audio decoding process starts with the ARM processor.
The audio bitstream is stored into SDRAM by the ARM
processor . When Teaklite core sends a request for a new
frame of audio stream using an interrupt to the ARM, the
requested audio stream is delivered to the core via Z-memory.
Teaklite core then starts processing the input audio stream
in the noiseless decoding module and in other subsequent
processing blocks. The processed stream is finally sent to the
IMDCT module in the FPGA. The decoded audio data is the
output of the IMDCT module and is stored in the SDRAM
first, then transmitted to the D/A converter in a serial format
by the audio controller. The audio controller includes a 64-tap
sampling rate converter. Note that the IMDCT module and Z-
memory exchange data with the SDRAM using a DMA and
do not take up the processing time of the ARM processor.
Small Memory Size To reduce the required memory size,
the Teaklite codes were manually programmed and optimized
in assembly codes. The X-, Y-, and Program-memories are
implemented as SRAMs inside the chip after the ASIC pro-
cess. To minimize the size of these SRAMs, the tables are
downloaded from the SDRAM each time data is needed.
32-bit Processing To improve the quality of the decoded
audio signal, we maintained all spectral data at 32-bit/sample.
The table entries were also kept at 32-bits except the IMDCT
table that used 24-bit entries.
Pipelining BSAC decoder operations are pipelined using
three pipeline stages as depicted in Fig 3. The first pipeline
stage F stands for Frequency domain processing (Noiseless
 Fig. 3. Pipeline Stages in BSAC
decoding, M/S, PNS, I/S, TNS), and the stage W stands for
Time domain processing (Windowing and Overlapping with
previous frame). These two stages, F and W, are processed
in Teaklite, while IMDCT is processed independently in a
hardware module. Teaklite processes the modules in the time
order denoted by small numbers, for example, 1F, 2W, 3F, 4W,
and so on. Note that there is no overlap between the pipeline
stages F and W at any time.
IV. V IDEO D ECODER
This section presents the real-time video decoder based on
H.264. The section starts with a discussion on the design
issues. Then, the hardware architecture is described.
A. Design Issues
There are a number of design issues that are specific to the
DMB video decoder. These issues, listed below, are reflected
in our FPGA implementation in the next section.
• Bandwidth: The DMB standard specifies the maximum
bit-rate for transmitting a MPEG-2 TS packet at different
protection levels. The portion of video streams in the
overall bit-rate ranges roughly from 500 Kbps to 1.5
Mbps. Considering the portability and mobility of the
DMB receivers, the broadcasting service providers favor
the protection level 2-A with the bit-rate of 572 Kbps
allocated to the video service.
• Low-power: The DMB video decoder is a portable device
and requires a low-power design. The amount of dynamic
power consumption depends on the number of switching
operations at the gate level. In our design of the DMB
video decoder, we achieve a low-power design on an
architectural level by reducing the number of memory
access and employing a low system clock frequency.
• High-performance: The real-time operation at 30 frames
per second requires that the video decoder processes and
displays each picture within the maximum processing
time of 33 msec. We minimize the number of bus access
and use pipeline processing techniques to achieve a
real-time operation at the lowest system and bus clock
frequency.
B. Architecture
The goal in the design of the DMB video decoder is to come
up with a low-power high-performance architecture. This goal
is achieved in our implementation by operating the decoder
at a low clock frequency. The architecture presented in this
section reflects this. In Figure 4, we show an overall block
Proceedings of the 4th IEEE International Workshop on System-on-Chip for Real-Time Applications (IWSOC’04)
0-7695-2182-7/04 $ 20.00 IEEE
Authorized licensed use limited to: Pusan National University Library. Downloaded on December 7, 2009 at 23:36 from IEEE Xplore. Restrictions apply.
Fig. 4. Block Diagram of H.264 Video Coder
diagram of the DMB video decoder. The functional blocks
are divided largely into 3 parts (parser, decoder, and display
parts). The first group of blocks, the parser part, consists of
the channel, RISC processor, and parser units that connect
the RF channel to SDRAM A on the A bus. The channel
unit receives the RF transmission of the DMB video stream
and stores into SDRAM A connected to the A bus. The RISC
processor unit then decodes the sequence parameter set, picture
parameter set, and slice layer header information of the H.264
video stream while managing the system level control signals.
The parser unit processes the remaining syntax elements at
the slice data layer and below. The decoded syntax elements
are written back to SDRAM A. The second group of blocks,
the decoder part, decodes the video stream stored in SDRAM
A and writes the decoded pictures in SDRAM B. First, the
entropy unit reads the CAVLC syntax elements from SDRAM
A, generates an array of transform coefficients, and sends to
the transform/quantization (T/Q) unit. The T/Q unit performs
inverse integer transform and dequantization to obtain the
residue data. The prediction unit reconstructs the image block
by computing intra/inter prediction values and adding to the
residue data from the T/Q unit. Finally, the deblock filter
unit filters the reconstructed data. The reconstructed image
blocks are stored into SDRAM B on the B bus. The third
group of blocks, the display part, performs functions related
to displaying the decoded and reconstructed video images
to the LCD screen. Each unit connected to the SDRAM is
equipped with a DMA (Direct Memory Access) unit. The bus
arbiter units control the bus access requests and the SDRAM
controller units manage the SDRAMs.
The main features of the architecture are (i) One Clock
System, (ii) Dual Bus System, and (iii) Two-Level Pipeline
Processing. We discuss each of these features next.
One Clock System The DMB video decoder is designed
as a simple one-clock system. That is, the codec unit and the
buses operate at the same clock frequency. This results in a
dual-bus two-level pipeline architecture as discussed later.
 Dual Bus System The DMB video decoder in Figure 4 is
a dual-bus system. The two buses, A bus and B bus, are both
32-bit wide and operate at the same bus clock frequency. The
parser and the decoder parts are connected to the A bus while
the decoder and the display parts are connected to the B bus.
During the decoding process, most of the bus access requests
arise for the B bus. The traffic on the A bus is thus relatively
lighter. Connecting the RISC processor to the A bus thus
allows a stable operation of the processor running other system
applications. Also, both buses can operate at a lower clock
frequency by splitting the bus traffic to two separate buses.
In our implementation, the parser part is separated out from
the rest of the decoder parts. The parser part communicates
with the decoder part through SDRAM A connected to the
A bus. This helps the decoder part to perform independently
of the parser part that is heavily affected by the bit-rate of
the incoming video sequence. Since the A bus is not used as
heavily as the B bus, the accesses to the A bus by the parser
part are accommodated easily.
Two-Level Pipeline Processing We employ a two-level
pipeline architecture in the DMB video decoder. First, the
parser part and the decoder part form a slice-level pipeline
structure. Then, the decoder part operates under a macroblock-
level pipeline structure. The pipeline architecture reduces the
overall decoding time by removing the idle intervals in the
decoder part. As a result, the video decoder can operate at
a lower system clock frequency. In the slice-level pipeline
process, each of the parser and the decoder parts becomes a
pipeline stage. In the parser stage, the parser part decodes the
incoming slice data and writes the resulting syntax elements
to SDRAM A. In the decoder stage, the decoder part starts
processing the syntax elements from SDRAM A. The two
pipeline stages are executed concurrently and SDRAM A
maintains two slices of video data, one for each pipeline stage,
during the decoding process. Each of the pipeline stages has
a variable execution time. Thus, the pipeline processing stalls
whenever the previous stages are not completed on time. The
second level pipelining is carried out on a macroblock-level
in the decoder part. Each tool unit of the decoder part does
not have the same processing time. If the macroblock-level
pipeline is not used, some tool units must stay idle, waiting
for the previous tool unit to send the processed data. We reduce
this idle intervals by allowing each tool unit to start processing
the next macroblock while transmitting the already-processed
macroblock to the subsequent tool unit. Each tool unit of the
decoder part has an internal buffering for two macroblocks.
While one macroblock is being processed and written to an
internal buffer, the macroblock data in the other buffer (that
has already been processed) is transmitted to the subsequent
tool unit.
V. P ERFORMANCE
In this section, we illustrate the performance of the portable
DMB receiver. The audio and video decoders have been
incorporated into the portable DMB receiver that has been
successfully demonstrated.
Proceedings of the 4th IEEE International Workshop on System-on-Chip for Real-Time Applications (IWSOC’04)
0-7695-2182-7/04 $ 20.00 IEEE
Authorized licensed use limited to: Pusan National University Library. Downloaded on December 7, 2009 at 23:36 from IEEE Xplore. Restrictions apply.
Fig. 5. Proportion of Decoding Time
A. Audio
The DMB audio decoder has been built and tested using
the Teaklite DSP and an FPGA board. To verify the error-free
operation of the decoder, we tested it with MPEG-4 ER BSAC
conformance bitstreams and compared the results with the 24-
bit references [9]. The decoder output was confirmed in every
test with sba mode = 0 where more than 17-bits matched
precisely with the references.
The SDRAMs used in the decoder includes 6KW (Kwords)
of program memory, 4KW of X-memory, 10KW of Y-memory,
1KW of Z-memory, and 2KW for the IMDCT module. Each
word was 16-bit long. In addition, 4KBytes of ROM was
assigned to store the tables used by the IMDCT module. The
total size of the memory used by the BSAC decoder was thus
50KBytes.
To decode audio streams at 44.1 KHz, 2 channel, and 96
Kbps, the total of 32 MIPS was required by Teaklite DSP. Out
of this, 17 MIPS was devoted to the BSAC noiseless coding
part (arithmetic coding). This is about 10 MIPS higher than
the MPEG-4 AAC counter-part, Huffman coding, which takes
only 6 MIPS in Teaklite DSP.
B. Video
The DMB video decoder has been built and tested on an
FPGA with the ARM920T processor and a display interface to
a 6.4-inch LCD screen. The video decoding process is divided
into 3 steps: (1) software parsing, (2) hardware parsing, and (3)
hardware decoding. In the software parsing step, the sequence
parameter set, picture parameter set, and slice header informa-
tion are parsed and entropy decoded by the ARM processor.
In the hardware parsing step, the slice data layers including
macroblock and sub-macroblock layers are parsed and entropy
decoded by hardware. The resulting syntax elements values are
written to SDRAM A. Finally, in the hardware decoding step,
the syntax elements are processed by the CAVLC decoder,
Transform & Quantization, Prediction, and Deblocking filter
blocks. The resulting video pictures are stored in SDRAM B
for display.
Figure 5 shows the proportions of decoding time needed
to process one slice by the three steps. The decoding time of
the hardware decoding step takes longer than both of the S/W
and H/W parsing steps summed together. Therefore, the total
decoding time is computed only from the decoding time of
the hardware decoding step.
The real-time operation of the video decoder was verified
using different sequences at the bit-rates ranging from 572
Kbps to 1.5 Mbps. In this paper, we illustrate the performance
 Tool Name Gate Count (%)
Parser 17
Entropy 9
Transform 6 on MPEG-4 BSAC while the video decoder was based on the
Prediction 33
Deblock Filter 26
IMDCT 1
TS DEMUX 9 will promote and enhance the Digitall
c
TABLE I
G ATE C OUNT P ROPORTIONS PER T OOL (T OTAL = 530K)
of the video decoder using two sets of test sequences at
different bit-rates. The first set of sequences were generated at
the bit-rate of 572 Kbps corresponding to the the Protection
Level A-2. The second set of sequences were generated at
the bit-rate of 1.5 Mbps corresponding roughly to the highest
bit-rate that the DMB standard allocates for the video stream.
The first four out of the five test sequences, Stefan, Foreman,
Coastguard, and Hall, are the MPEG standard test sequences
while the last sequence is the scenes extracted from the
movie “Fly Away Home” (Columbia Pictures, 1996). Each
sequence contained 300 frames with an IDR-frame inserted
every 0.5 seconds. The results show that the low bit-rate
(572 Kbps) sequences are real-time decoded at the operation
clock frequency of 14.5 MHz. The higher bit-rate (1.5 Mbps)
sequences are decoded at the clock frequency of 15.5 MHz. We
conclude that our FPGA implementation of the DMB video
decoder operates at a low clock frequency of 14.5 ∼ 15.5
MHz.
C. System
The bus clock and the processing clock are derived by
a single clock at the same frequency in the DMB receiver.
The operation frequency of the overall system was set at
25 MHz. This frequency is the typical operation frequency
required by the 6.4-inch 640 × 480 LCD display attached to
the receiver. Since other parts of the receiver operate well
under this frequency, the overall system frequency was set at
this value.
The gate count of our DMB video decoder was esti-
mated using Samsung Semiconductor’s Standard Cell Library
(STDL130) implemented in the 0.18 µm L18L process tech-
nology. The total count was estimated to be 530,000 gates.
The proportions in each tool are shown in Table I.
The DMB receiver presented here has been verified by a
series of conformance tests. The tests were conducted using
the test broadcasts from the participating national broadcasting
corporations in Korea. The portable DMB receiver performed
successfully in real-time both in a laboratory environment and
during the field tests carried out on a moving vehicle.
Proceedings of the 4th IEEE International Workshop on System-on-Chip for Real-Time Applications (IWSOC’04)
0-7695-2182-7/04 $ 20.00 IEEE
Authorized licensed use limited to: Pusan National University Library. Downloaded on December 7, 2009 at 23:36 from IEEE Xplore. Restrictions apply.
VI. C ONCLUSION
We presented the real-time portable receiver for Digital
Multimedia Broadcasting in Korea. The receiver was designed
using DSP and FPGA boards. The audio decoder was based
Baseline profile of MPEG-4 Part10 AVC/H.264 at Level 1.3.
Our DSP/FPGA implementation of the portable DMB receiver
consisted of about 530K gates and operated at the overall
clock frequency of 25 MHz. We believe that the DMB service
lifestyle of its users
by providing various kinds of information and entertainment
services at anytime and at any place.
VII. ACKNOWLEDGEMENT
Authors would like to thank the members of Mobile Solu-
tion Lab in the Digital Media R&D Center, Samsung Elec-
tronics and the members of ETRI (Electronics and Telecom-
munications Research Institute) in Korea for participating in
the development of the DMB standard and the portable DMB
receiver.
R EFERENCES
[1] “Digital Multimedia Broadcasting,” Telecommunications Technology As-
sociation, 2003SG05.02-046, 2003.
[2] “Radio Broadcasting System: Digital Audio Broadcasting (DAB) to
mobile, portable and fixed receivers,” ETSI EN 300 401 v1.3.3, May
2001.
[3] “Coding of audio-visual objects part 3: Audio,” ISO/IEC 14496-3:1999.
[4] “Draft ITU-T recommendation and final draft international standard of
joint video specification (ITU-T Rec. H.263/ISO/IEC 14496-10 AVC,”
Joint Video Team (JVT) of ISO/IEC MPEG and ITU-T VCEG, JVT-
G050, 2003.
[5] S. W. Kim, S. H. Park, and Y. B. Kim, “Fine grain scalability in MPEG-4
audio,” in The 111th Audio Eengineering Society Convention, September
2001.
[6] Thomas Wiegand, Gary J. Sullivan, Gisle Bjontegaard, and Ajay Luthra,
“Overview of the H.264/AVC video coding standard,” IEEE Transactions
on Circuits and Systems for Video Technology, vol. 13, no. 7, pp. 560–
576, 2003.
[7] Seung-Gi Chang, Victor H. S. Ha, Zhi-Ming Zhang, and Yong-Je Kim,
“Performance evaluation of Eureka-147 with RS(204,188) code for mo-
bile multimedia broadcasting,” in SPIE’s Visual Communications and
Image Processing, July 2003, pp. 934–940.
[8] Seung-Gi Chang, Ga-Hyun Ryu, Victor H. S. Ha, and Yong-Je Kim,
“Standardization and implementation of DMB (Digital Multimedia
Broadcasting) system in Korea,” in International Technical Conference
on Circuits/Systems, Computers and Communiations, July 2003, vol. 2,
pp. 933–936.
[9] “Conformance testing,” ISO/IEC JTC1/SC29/WG11 N2204, February
1998.