Fast CAVLD of H.264/AVC on bitstream decoding processor

Abstract

This paper presents a fast context-based adaptive variable-length decoding (CAVLD) method of H.264/AVC with a very long instruction word-based bitstream processing unit (BsPU) designed for entropy decoding of multiple video formats. A new table mapping algorithm for the coeff_token, level, and run_before syntax elements of the quantized transform coefficients is proposed, and many branch operations are removed by utilizing several designated instructions in the BsPU. By applying designated instructions and the proposed table mapping algorithm to CAVLD, we found that the proposed fast CAVLD method achieves an increase of approximately 47% in the decoding speed and a reduction of approximately 59% in memory requirements for the table mapping.

1. Introduction

The recent evolution of digital media technologies has enabled users to use numerous video applications, even on mobile devices, through diverse network channels. Along with these communication and hardware implementation technologies, various video compression technologies have been developed not only by standard bodies, but also by private companies. The ISO/IEC Moving Picture Expert Group (MPEG) and the ITU-T Video Coding Expert Group (VCEG) have released multiple video compression standards: MPEG-1/2/4 and H.261/262/263/264. Among them, H.264/AVC is considered to be a major video coding standard, owing to its coding efficiency. It was developed by a Joint Video Team, which was a temporary group formed by the MPEG and VCEG bodies [1]. These video coding standards have been widely used for mass production applications such as broadcasting, media players, and mobile video services. Moreover, these video codecs have been vigorously implemented in hardware circuits for huge markets. On the other hand, there are many other video coding technologies, such as the On2 series and VC-1. Even though these technologies were not developed by international standards bodies, they have been widely used in the market, especially for personal computer (PC) applications with software implementation. However, since the advent and widespread use of smartphones, video codecs are no longer just for the PC platform. As smartphones proceed in replacing conventional cellular phones, many video codecs are being considered for mobile devices. Mobile devices have one major limitation: light batteries. Video codecs for mobile devices are commonly implemented in hardwired circuits for lower power consumption. However, it is difficult to implement all video codecs in hardware logic because of development costs, design time, and lack of flexibility. For new video codecs, many developers should be prepared for long development times and high financial costs in developing and debugging hardware logics.

On the other hand, software-based multi-format video decoders have been developed on multi-core platforms. Various parallel implementations are utilized to alleviate the implementation costs of multi-format decoders with hardwired circuits. On the multi-core platform, it is possible to develop multi-format decoders that allow easy performance evaluation with minimum cost and effort compared to other hardwire designs. In addition, the multi-core platform requires less power for fast decoding of multi-format multimedia content due to the low clock speed. Parallel video decoders with multi-core platform can be implemented based on both data-level and functional-level parallelism. However, considering resolution, scalability, and performance in parallelism, the macroblock-level parallelism approach, which is a form of data-level parallelization, is widely used for video decoders [2]–[4]. For macroblock-level parallelism, the 2D wave-front approach is widely known and used. This method can perform parallel decoding of multiple macroblocks without any decoding dependencies. However, this 2D wave-front approach cannot be used for entropy decoding because of bit-by-bit dependency in a slice, even though back-end decoding can be parallelized with the multi-core platform [5]. Because the performance of parallel video decoders is highly influenced by sequential parts such as entropy decoding, the high-performance entropy decoder is an essential prerequisite for parallel video decoders. In addition, entropy decoding is one form of bottleneck that can decrease decoding throughput not only in parallel decoders but also in sequential decoders, especially for high-bitrate streams.

H.264/AVC supports two entropy coding techniques: context-based adaptive variable-length coding (CAVLC) and context-based adaptive binary arithmetic coding (CABAC). CABAC provides a coding gain of approximately 10% ~ 15%, compared with CAVLC. However, it has high computational complexity and requires a large number of serial operations. With software-based implementations, it is difficult to achieve real-time decoding for CABAC for such high bitrate ranges [6]–[8]. The CAVLC mode is also widely used, not only for mobile devices, but also for many other high-quality applications through baseline and main profiles. Although context-based adaptive variable-length decoding (CAVLD) has less computational complexity than context-based adaptive binary arithmetic decoding (CABAD), the CAVLD is also considered to be one of the most complex variable-length decoding (VLD)-based entropy decoders in the market. We can state that a platform capable of implementing CAVLD in real time can also decode other VLD-based entropy decoders. In this paper, a fast CAVLD implementation is presented with a developed bitstream processing unit (BsPU) based on a table mapping algorithm. Note that the BsPU has multiple designated instructions for entropy decoding. The new table mapping algorithm is applied to several syntax elements such as coeff_token, level, and run_before. In addition, certain designated BsPU instructions are efficiently used to reduce the number of branches in arithmetic computations.

The rest of the paper is organized as follows. In section 2, the conventional entropy decoding algorithms and the BsPU are introduced. In section 3, the proposed fast CAVLD based on a new table mapping algorithm is presented. In section 4, experimental results are shown and discussed. Finally, concluding remarks are given in section 5.

2. H.264/AVC CAVLD and its conventional acceleration algorithms

CAVLD is considered to be a bottleneck in both parallel and sequential decoders of H.264/AVC because of its bit-by-bit dependency. Furthermore, as video resolution is increasing based on market demands, the common bitrate for high-resolution videos such as full high definition (full HD) now ranges from 10 to 20 megabits per second (Mbps) for high-quality applications. For such high-bitrate applications, a portion of the complexity for the entropy decoding would significantly increase. For fast CAVLD of H.264/AVC, there are several algorithms such as table mapping, which can improve the overall latency of entropy decoding without parallelism. In order to develop an efficient table mapping approach for multi-stage pipelined processors, it is necessary to consider not only the memory requirements and the number of memory accesses, but also the number of conditional branches.

2.1 CAVLD of H.264/AVC

CAVLC is one of the entropy coding methods of H.264/AVC to encode quantized transformed coefficients in 4 × 4 (or 2 × 2) blocks. CAVLC employs some characteristics to improve coding efficiency as follows: (1) Run-level coding is more effective to encode strings of zero coefficients after zig-zag scanning. (2) After zig-zag scanning, non-zero coefficients in high frequency are likely to be ±1. CAVLC refers to the number of ±1 coefficients as TrailingOnes and encodes it. (3) The number of non-zero coefficients is highly correlated with those of neighboring blocks. CAVLC refers to the number of non-zero coefficients as TotalCoeff and uses different variable-length coding (VLC) tables depending on the number of non-zero coefficients of neighboring blocks. (4) The levels of non-zero coefficients tend to be higher near low-frequency components. Hence, CAVLC adaptively selects the VLC table to encode the current level value depending on the associated previous coded level. The zig-zag scanned coefficients are represented by five types of syntax elements. These syntax elements are defined as follows:

• 1. coeff_token: This syntax element specifies both TotalCoeff and TrailingOnes.

• 2. trailing_ones_sign_flag: This syntax element specifies the sign of a coefficient in TrailingOnes.

• 3. level_prefix and level_suffix: These syntax elements specify the value of a non-zero coefficient level except for TrailingOnes.

• 4. total_zeros: This syntax element specifies the number of zero coefficients preceding the last non-zero coefficient.

• 5. run_before: This syntax element specifies the number of consecutive zero coefficients preceding each non-zero coefficient including TrailingOnes.

Figure 1 shows a flowchart of CAVLD and the decoding procedure with an example bitstream of a 4 × 4 block. The process of CAVLD consists of six steps, as shown in Figure 1. In this example, the average number of non-zero transform coefficients of the top and left blocks is assumed to be five. After the decoding procedure for the 4 × 4 block, zig-zag scanned coefficients, {0, 3, 0, 1, −1, −1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0}, are reconstructed.

Figure 1

CAVLD flowchart and procedure for an example 4 × 4 block.

2.2 Conventional fast entropy decoding algorithms

Many previous studies on fast implementation of CAVLD have proposed the use of hardwire logic [9]–[11]. However, hardware implementations have many drawbacks such as the long development period, the large silicon area, and the low reusability of multi-format video decoders, as previously mentioned. This paper focuses on fast entropy decoding algorithms for processor-based implementations. The simplest approach is the table lookup by sequential search (TLSS) as implemented in the joint model (JM) reference software [12]. TLSS finds symbols by comparing all possible codewords with part of the input bitstream. This approach requires a large number of comparisons and therefore cannot be used for real-time applications. Table lookup by binary search (TLBS) has also been proposed to improve the entropy decoding speed. The codewords are rearranged into a binary search tree structure, and the symbols can be extracted from the tree by using binary search. TLBS offers much better performance than TLSS; however, a more efficient implementation is needed for real-time applications.

On the other hand, several conventional algorithms can be used to reduce the number of memory accesses. Moon et al. [13] proposed a fast decoding method for coeff_token and run_before in the CAVLD of H.264/AVC. It is based on arithmetic operations and works by considering the characteristics of the associated codewords. This approach does not require memory access and repeated comparisons; however, many conditional branches might be involved, depending on the codewords used. Another memory-efficient CAVLD for fast entropy decoding [14] was presented to accelerate coeff_token, run_before, and total_zeros based on arithmetic operations. In this study, codewords were categorized, and several arithmetic operations were proposed for each category. This algorithm is known to be more effective than Moon's algorithm; however, it also requires many conditional branches. Frequently occurring conditional branches are not suitable for multi-stage pipelined processors because wrong branch prediction can significantly reduce performance of the processors. Although many multi-stage pipelined processors have their own branch prediction units, the performance of the modules depends on the applications. In particular, the performance of instruction-level parallelism can be further degraded by wrong branch prediction for many digital signal processors (DSP) based on the very long instruction word (VLIW) architecture. For multi-stage pipelined processors, a reduction in the number of conditional branches is also important along with a reduction in the number of memory accesses and the table memory requirement [15]. Many table-based algorithms have been proposed for a number of entropy decoders based on VLD because these approaches are known to be fast and have a large redundant memory allocation [16]–[19].

As shown in Figure 2, the table mapping algorithm tries to find the correct symbol using memory addressing with the maximum-length syntax element (in bits). Note that the length is that of the longest codeword for the syntax element. However, the table memory requirement increases exponentially by 2ⁿ, where n is the length of the longest codeword. In addition, such high memory requirements can cause frequent cache misses, which have a significant impact on overall performance. Thus, the memory requirement needs to be reduced. One fast entropy decoding algorithm based on table mapping was proposed for coeff_token in CAVLD [20]. This algorithm divides the mapping table for coeff_token depending on the number of leading zeros. Multiple tables are required, but the total memory requirements can be reduced using multiple small tables. However, in practice, this approach is not suitable for pipelined processors because conditional branches might be involved in the choice of one of the four tables before table indexing.

Figure 2

Original codeword table and new table for table mapping.

For coeff_token decoding, a multi-level table mapping algorithm was proposed [21]. The first 8-bit codeword is decoded using a table mapping algorithm, and the rest of the bits are then decoded with one branch operation and an additional table mapping algorithm. This algorithm reduces the amount of table memory; however, it frequently suffers from pipeline stalls caused by branch operations.

For the level and run_before syntax elements, the multi-level table mapping algorithms [22] are also used for fast decoding. The level syntax element is represented with the Exp-Golomb code, the codewords of which have leading zeros which are less than 15. The first 8-bit codeword is decoded using table mapping, and the rest of the bits are decoded using arithmetic operations by employing characteristics of Exp-Golomb. Codewords with more than 15 leading zeros before the separator require exceptional handling. This algorithm also requires several conditional branches. For the run_before syntax, one of multiple tables is selected based on the number of zeros among the rest of coefficients to be decoded. When the number of zeros is greater than six, a larger mapping table is required. In this case, two-stage table mapping should be employed to reduce the amount of memory. For the remaining cases, one table mapping algorithm can perform the entire entropy decoding. This algorithm can significantly reduce the table memory requirement; however, many conditional branches should be involved, and these can reduce overall performance of entropy decoding with a multi-stage pipelined processor.

2. 3 Bitstream processing unit

Entropy decoding is a process whereby a codeword is converted into a number or symbol. The codeword is loaded from external memory into internal memory in the entropy decoding process. In addition, the operations in the entropy decoding are mostly bit-level operations. However, frequent accesses to the external memory can significantly degrade decoding performance. To resolve this problem and achieve real-time decoding with a flexible design, it is desirable to use a designated bitstream decoding processor.

The combination of a bitstream decoding processor and parallel back-end decoding is useful for implementing a real-time multi-format decoder with low power consumption. This paper uses the BsPU that consists of a reconfigurable processor (RP) [23] and multiple instructions for multi-format bitstream decoding. Note that we also developed the BsPU by developing new instructions and hardwire logics on the RP, which is an elaboration of ADRES [24]; however, in this paper we will focus on the fast H.264/AVC CAVLD on the BsPU. The BsPU is based on a VLIW architecture and six additional instructions for bitstream decoding, as shown in Table 1. The Showbits instruction is for outputting as many bits as required. The Getbits instruction is for outputting as many bits as required and moving a pointer to the next bit after the bits used. The Skipbits instruction is for skipping as many bits as required. These three instructions are widely used for bitstream access and can be used to reduce the number of cycles required. The count leading zeros (CLZ) instruction is for determining the number of consecutive zeros in a bitstream and is used in reduced instruction set computer processors [25] and many other DSPs. This instruction would be very useful for decoding some syntax elements coded with Exp-Golomb. The BsPU contains an instruction called I_ONERETURN with two input parameters, A and B. When A is 1, this operation returns B; otherwise it returns ‘0’ as an output. This operation can be implemented using multiplication; however, the RP requires 3 cycles for multiplication. The I_ONERETURN instruction requires only 1 cycle and is therefore more effective than multiplication for removing conditional branches.

Table 1 BsPU instructions for multi-format bitstream decoding

3. Proposed fast CAVLD for BsPU

In this paper, a new fast CAVLD algorithm which uses dedicated instructions for table mapping is proposed. To reduce the number of branch operations, the various instructions are carefully organized to improve overall performance. As the three syntax elements, coeff_token, level, and run_before occupy a large fraction of computation time, we propose a new table mapping algorithm for them with several instructions in the BsPU. In contrast, the trailing_ones_sign_flag can be easily decoded because the length is known as the TrailingOnes. For the total_zeros syntax element, we also employed the table mapping algorithm. However, the decoding algorithm is conceptually the same as the simple table mapping algorithm. It allocates 2⁹ entries for a table for total_zeros_syntax element since the longest code word has 9 bits.

3. 1 Proposed fast decoding for the coeff_token syntax element

Four codeword tables are used for the coeff_token syntax element in H.264/AVC CAVLD. One of these four tables is selected depending on the average number of non-zero transform coefficient levels of the top and left blocks, which is denoted nC, as shown in Table 2. Three of these ones are variable-length tables, and the last one is a fixed-length table. For the variable-length tables, each codeword consists of three parts: a prefix, the number ‘1’, and a set of remainder bits. The prefix consists of consecutive zeros, and the remainder bits are an arbitrary sub-codeword with a length of less than or equal to 3. In the proposed algorithm, each of the three VLC tables is divided into multiple divisions depending on the number of consecutive zeros in order to achieve fast table mapping with minimum memory size. After implementation of a single table mapping for each table, there will be 2¹⁶ entries, because the longest codeword bit length is 16. In the proposed algorithm, the length of divided divisions for VLC T0 is 8 (=2³) to avoid any conditional branches regardless of the number of entries. As a result, the required number of entries is 120 (=15 × 2³) for the VLC T0, because the number of divisions is 15. On the other hand, the required number of entries for the fixed-length coding (FLC) case is 2⁶, and the table can be accessed with a 6-bit address. Figure 3 shows a part of the reorganized tables for coeff_token. TrailingOnes and TotalCoeff are assigned by the remainder and quotient from division of the ‘coeff’ in the second table by four, respectively. Figure 4 shows two different methods to decode the syntax element for the VLC and FLC cases, depending on the value of nC. A branch operation is needed to distinguish the two cases. This paper proposes a single consolidated decoding algorithm for coeff_token without any branch operations. The following is the pseudo-code for the consolidated decoding algorithm of coeff_token.

Table 2 Four tables for the coeff_token depending on nC

Figure 3

Proposed two-stage coeff_token decoding table.

Figure 4

Two different decoding modes for VLC and FLC.

In the first step, the table index is obtained, using nC. Then, the 32-bit bitstream is read. In the third step, zero_num is set to the number of leading zeros in those 32 bits. In step 4, the flag indicates whether a VLC table or the FLC table is needed. The indicator flag2 contains the number of zeros in the VLC case (or is zero in the FLC case). Therefore, this number serves as the division index for the VLC case. In the FLC case, there is only one table and the division index is zero. In the sixth step, the address of the desired division is obtained using the VLC table index. In the FLC case, the start address of the FLC table is returned. In the seventh step, the bits in the prefix and the separator ‘1’ are discarded in the VLC case; however, no bits are discarded in the FLC case. In the eighth step, 3 and 6 bits are loaded for the VLC and FLC case, respectively, in order to specify the address for the mapping table. In the ninth step, the desired value is obtained from the reorganized table using the address. In the last step, the processed bits are discarded to prepare for the next bitstream decoding operation.

3.2 Proposed fast decoding for the level syntax element

H.264/AVC uses seven VLC tables for the level syntax element. For the first level value, the Level_VLC0 or Level_VLC1 table is used depending on the context. If the number of non-zero coefficients is greater than ten and the number of TrailingOnes is less than three, the Level_VLC1 table is selected; otherwise, Level_VLC0 is used for the first level value. For the second level value, when the decoded level value is greater than a threshold defined for each step, the next VLC table is used. The thresholds for the seven VLC tables are {0, 3, 6, 12, 24, 48, N/A}.

The VLC table for the level syntax element is essentially based on Exp-Golomb. The number of remainder bits is determined by the number of leading zeros. Then, a known arithmetic operation is used to decode Exp-Golomb-coded syntax elements. Table 3 shows the codewords and corresponding levels for Level_VLC1. As shown in the table, the length of the codeword varies depending on the number of leading zeros until this value is less than 15. Because of the exception, branch operations could be required.

Table 3 Codewords and corresponding levels for LEVEL_VLC1

It is inefficient to use the table mapping algorithm alone for the level syntax element because the table memory requirement is huge. This paper proposes a two-stage table mapping algorithm using arithmetic operations with one condition. As shown in Figure 5, if the number of leading zeros is greater than or equal to 16, arithmetic operations are used for level decoding. Otherwise, the two-stage table mapping algorithm is used. As shown in Figure 6, the next table index, the length of remainder bits, and the starting address of the coefficient table are accessed using the number of leading zeros as an index. Addition or comparison is not needed to identify the next table to be used according to the threshold because the next table index is obtained from the first-stage table mapping operation. After the process of leading zeros table mapping in Figure 5, the processed bits are discarded. The coefficient table for the second table mapping is used with a number of bits equal to the number of remainder bits from the first table. H.264/AVC utilizes seven coefficient tables depending on the VLC level number. However, the proposed algorithm consolidates all these coefficient tables into one, as shown in Figure 6. The coefficient level value in the consolidated coefficient table ranges from −2,528 to +2,528. From the starting address of the first table, the coefficient level value can be retrieved using the number of remainder bits as an index. After coefficient table mapping, the remainder bits are discarded.

Figure 5

Flowchart for decoding operation of the level syntax element.

Figure 6

Proposed two-stage decoding table for level syntax element.

3.3 Proposed fast decoding for the run_before syntax element

The run_before syntax element indicates the number of zero coefficients between two consecutive non-zero coefficients. This syntax element has seven tables depending on the number of remaining zero coefficients to be decoded. A table mapping method that does not need branch operations for table selection is proposed, and the consolidated table for the proposed decoding method of the run_before syntax element is as follows: The maximum codeword length from run_before_T0 to run_before_T5 is 3; therefore, six tables with 2³ entries each are needed. For the last table, run_before_T6, the maximum number of codeword bits is 11; therefore, a mapping table with 2¹¹ entries must be used for direct memory access. However, only one codeword in the table consists of 11 bits. Therefore, the codewords can be identified by checking the first 10 bits only, so the proposed mapping table for run_before_T6 consists of 2¹⁰ entries as shown in Figure 7. The proposed pseudo-code for fast decoding of the run_before syntax element is presented as follows:

Figure 7

Proposed decoding table for run-before syntax element.

In step 1, the table number is determined, with zeroleft representing the total number of zero coefficients to be decoded. The run_before_T6 is used in the case that zeroleft is greater than 6. Otherwise, the table number is selected based on the zeroleft value. In general, a branch operation is needed to decide whether zeroleft is greater than 6. However, in the proposed design, the I_MIN instruction in Table 1 is used to eliminate the branch operation. In step 2, 10 bits are loaded for consecutive decoding. In step 3, the I_ONERETURN instruction is used to carry out table mapping with all 10 bits for run_before_T6 and with only 3 bits for the remaining tables. In step 4, the run_before value is retrieved by using table mapping with the table number and the associated index. In step 5, the processed bits are discarded.

4 Experimental results and discussion

To evaluate the performance of the proposed algorithm, the number of cycles for H.264/AVC CAVLD is investigated with a RP simulator. We compared the proposed algorithms with Kim's method [14], Iqbal's method [20], the multi-level table mapping (MTM) method [21], and open-source software (FFmpeg) [22] in the sense of CAVLD cycles and required memory for various video sequences.

4. 1 Experimental conditions and environment

The performance of bitstream decoding is related to not only the characteristics of video sequences but also their bitrates. For this reason, we used several sequences (720p and full HD) for the evaluation. Table 4 shows test sequences, their resolutions, and bitrates. For 720p, ‘Parkrun’, ‘Shields’, and ‘Mobcal’ sequences were used. In addition, ‘Blue_sky’, ‘Riverbed’, and ‘Station2’ sequences were used for the full HD test. The encoding conditions are shown in Table 5. We used JM 17.2 reference software to encode the test sequences with multiple quantization parameter (QP) values. By using multiple QP values, we can evaluate the performance of CAVLD algorithms for various bitrates. In addition, we used both IPPP and IBBBP coding structures for thorough analysis because the number of zero value coefficients could vary depending on P and B slices.

Table 4 Test sequences and their bitrates

Table 5 Encoding conditions for test bitstreams

As mentioned before, we developed a new table mapping algorithm for CAVLD and designated instructions for multi-format bitstream decoding. The added instructions, Showbits, GetBits, and Skipbits instructions run in 2 cycles, and the other instructions, CLZ and I_ONERETURN, run in 1 cycle. To evaluate the performance of the new table mapping algorithm for the coeff_token, level, and run_before syntax elements, we used a developed CAVLD decoder and compared the decoding cycles of the CAVLD. For example, to evaluate algorithms for coeff_token decoding, we just replaced the proposed algorithm for coeff_token with other conventional algorithms for the syntax element. In that case, the designated instructions are also applied not only for the proposed table mapping algorithm but also for the conventional algorithms.

4.2 Performance evaluation of the proposed algorithm and several conventional algorithms for CAVLC syntax elements

Table 6 shows the numbers of megacycles per second (MCPS) required by the proposed and conventional algorithms for the coeff_token syntax element and cycle reduction ratio (CRR) of the proposed algorithm, compared with the conventional algorithms. Kim's method does not use any table mapping operations except for arithmetic operations. The rest of the algorithms are based on table mapping. Table 6 shows that the table mapping-based algorithms are generally more effective than the arithmetic-based one. Compared with Kim's method, the proposed algorithm is 17.2% and 17.3% faster for IPPP and IBBBP coding structures, respectively, and it just requires 0.718 kB of memory for the table mapping. As shown in Table 6, the proposed algorithm is around 8% faster than Iqbal's method. The proposed algorithm and Iqbal's algorithm are based on table mapping. The only difference is that the proposed algorithm omits the branch operations. We can state that by omitting branch operations, the proposed algorithm reduces the number of cycles by avoiding pipeline stall in multi-stage pipelined processors. Note that the proposed algorithm is more appropriate on various target systems because it does not cause pipeline stall and it is not affected by the performance of branch prediction. The cycle requirement of the proposed algorithm is almost the same as those of the MTM method. However, the proposed method reduces the memory requirements by approximately 88%. In summary, the proposed algorithm achieves a small number of cycles with a minimum memory requirement for coeff_token decoding.

Table 6 Comparison of MCPS and memory requirements for coeff_token syntax element

Table 7 shows the numbers of MCPS and the memory requirements required by the proposed and conventional algorithm for the level syntax, and CRR of the proposed algorithm, compared to the conventional algorithms. The number of cycles used by the proposed algorithm is reduced by 10.7% and 10.4% for IPPP and IBBBP coding structures, respectively, compared with the MTM method. For the level syntax element, the proposed algorithm and the MTM method require 9.937 and 3.5 kB, respectively. The proposed algorithm requires approximately 6 kB more than the MTM method for an approximate 11% speedup.

Table 7 Comparison of MCPS and memory requirements for level syntax element

Table 8 shows the numbers of MCPS, the memory requirements of the proposed and conventional algorithms for the run_before syntax, and CRR of the proposed algorithm. The number of cycles used by the proposed algorithm is reduced by approximately 7% and 5%, compared with the MTM method and the arithmetic-based (Kim's) method, respectively. The MTM algorithm uses both table mapping and arithmetic methods, but Kim's method uses only arithmetic operations. The two conventional algorithms use conditional branches for table selection. However, the proposed algorithm involves no branch operations. As for the memory requirements, the proposed algorithm requires 2.109 kB; however, they can easily be loaded into the target system.

Table 8 Comparison of MCPS and memory requirements for run_before syntax element

In this work, we implemented our own CAVLD to fully exploit the developed instructions along with the proposed table mapping algorithms for coeff_token, level, and run_before syntax elements. To evaluate the high-performance CAVLD algorithm, the developed CAVLD is evaluated by comparing the open H.264/AVC decoder (FFmpeg). Note that JM is not a proper platform for decoding speed evaluations because JM is around two times slower than the FFmpeg software for CAVLD.

Table 9 shows decoding cycles of the proposed CAVLD and FFmpeg one for various QP values. For evaluation of the proposed instructions for the BsPU, we compared decoding cycles between FFmpeg and modified FFmpeg with the proposed instructions. We found that we can save 38% cycles by applying the proposed instructions to the FFmpeg CAVLD. Because Showbits, Getbits, and Skipbits are frequently called for CAVLD, these can be accelerated into 2 cycles with the proposed instructions. For evaluation of the proposed algorithm, the developed CAVLD and modified FFmpeg are compared using the proposed instructions. As a result, we found that the proposed algorithm is 13.5% and 13.0% faster than the modified FFmpeg with the proposed instructions for IPPP and IBBBP coding structures, respectively. We can say that BsPU is effective with the proposed table mapping algorithm that does not cause any branches. In addition, the proposed CAVLD with instructions and table mapping algorithm can save 46.6% and 46.2% cycles for IPPP and IBBBP coding structures, respectively, compared with FFmpeg CAVLD without the proposed instructions. At the same time, we can save the required memory from 73.6 to 30.1 kB. The cycle reduction of the proposed CAVLD is persistent regardless of QP values.

Table 9 Comparison of MCPS for CAVLD

5. Conclusions

In this paper, a novel fast CAVLD method is proposed with table mapping and new dedicated instructions for fast entropy decoding of H.264/AVC. The proposed algorithm reduces the number of cycles to about 8% ~ 17% from coeff_token, 11% from level, and 5% ~ 7% from run_before, respectively. In addition, the proposed CAVLD is enhanced with the proposed several instructions for the BsPU along with the table mapping. By comparing the developed CAVLD with the FFmpeg one, we achieved a 47% reduction in the number of cycles, compared with FFmpeg CAVLD. In addition, the proposed algorithm reduces the memory requirements for table mapping by approximately 59% compared with FFmpeg on the RP that is commercially used in a smartphone. In the future, we will focus on the development of CABAD on the BsPU.

Acknowledgments

This research was partly supported by Samsung Electronics, the MKE (The Ministry of Knowledge Economy), Korea, under the ITRC (Information Technology Research Center) support program (NIPA-2013-H0301-13-1006) supervised by the NIPA (National IT Industry Promotion Agency), and Kwangwoon University during the sabbatical year of 2011.