Real-time Audio/video Decoders For Digital Multimedia Broadcasting

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 [email protected]

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 Eureka147 [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 nationwide coverage. In this paper, we introduce the portable receiver for terrestrial 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 MPEG4 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 bitrate 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 summarizes 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 bitrates 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 bitsliced 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 bitslice. 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.

2) BSAC in DMB: The audio service in DMB should support the standardized stereo audio broadcasting at the sampling rates of 24, 44.1, or 48 KHz. The service should provide CDquality 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 adaptive 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 international video coding standard developed by Joint Video Team (JVT) consisting of experts from ITU-T’s Video Coding Experts 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 example, 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 efficiency 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 implemented with 16-bit integer arithmetic operations. The conditional 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).

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.

The goal of Network Abstraction Layer (NAL) is to provide “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 applicationdependent 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 (redundant 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 motion 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.

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 mobile 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 Zmemory 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 process. 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

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. 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.

Fig. 4.

Block Diagram of H.264 Video Coder

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

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.

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.

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 macroblocklevel 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.

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 24bit 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 information 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

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.

Tool Name

Gate Count (%)

Parser

17

Entropy

9

Transform

6

Prediction

33

Deblock Filter

26

IMDCT

1

TS DEMUX

9

TABLE I G ATE C OUNT P ROPORTIONS PER T OOL (T OTAL = 530K)

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 on MPEG-4 BSAC while the video decoder was based on the 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 c lifestyle of its users will promote and enhance the Digitall
by providing various kinds of information and entertainment services at anytime and at any place. VII. ACKNOWLEDGEMENT

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 estimated using Samsung Semiconductor’s Standard Cell Library (STDL130) implemented in the 0.18 µm L18L process technology. 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.

Authors would like to thank the members of Mobile Solution Lab in the Digital Media R&D Center, Samsung Electronics and the members of ETRI (Electronics and Telecommunications 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 Association, 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, JVTG050, 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 mobile 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.

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.