- Research
- Open Access

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

- Jung-Han Seo
^{1}, - Hyun-Ho Jo
^{1}, - Dong-Gyu Sim
^{1}Email author, - Doo-Hyun Kim
^{2}and - Joon-Ho Song
^{2}

**2013**:23

https://doi.org/10.1186/1687-5281-2013-23

© Seo et al.; licensee Springer. 2013

**Received:**31 August 2012**Accepted:**3 April 2013**Published:**26 April 2013

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

## Keywords

- CAVLD
- H.264/AVC
- Entropy decoding
- Video compression

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

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

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

^{ n }, 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.

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.

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

**BsPU instructions for multi-format bitstream decoding**

Instruction | Description |
---|---|

Showbits( | The Showbits instruction reads |

Getbits( | The Getbits instruction reads and skips |

Skipbits( | The Skipbits instruction skips |

CLZ | The CLZ instruction counts leading zeros |

I_ONERETURN( | If input |

I_MIN( | I_MIN instruction returns the minimum value between |

## 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^{9} 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^{16} entries, because the longest codeword bit length is 16. In the proposed algorithm, the length of divided divisions for VLC T0 is 8 (=2^{3}) to avoid any conditional branches regardless of the number of entries. As a result, the required number of entries is 120 (=15 × 2^{3}) 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^{6}, 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.

**Four tables for the coeff_token depending on**
nC

Table number | Selection condition | Table name |
---|---|---|

0 | 0 < = | VLC T0 |

1 | 2 < = | VLC T1 |

2 | 4 < = | VLC T2 |

3 | 8 < = | 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}.

**Codewords and corresponding levels for LEVEL_VLC1**

Codeword | Level |
---|---|

10 | 1 |

11 | −1 |

010 | 2 |

011 | −2 |

… | … |

0000 0000 0000 0011 | −15 |

0000 0000 0000 0001 xxxx xxxx xxxx | ±16… |

0000 0000 0000 0000 1xxx xxxx xxxx xx | ±2064… |

### 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^{3} 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^{11} 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^{10} entries as shown in Figure 7. The proposed pseudo-code for fast decoding of the run_before syntax element is presented as follows:

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

**Test sequences and their bitrates**

Resolution | Sequences | QP | Bitrate (Mbps) | FPS (frame/s) | |
---|---|---|---|---|---|

IPPP | IBBBP | ||||

HD | Parkrun | 22 | 54.2 | 52.1 | 30 |

28 | 22.8 | 20.5 | 30 | ||

34 | 8.5 | 8.0 | 30 | ||

Shields | 22 | 25.4 | 23.2 | 30 | |

28 | 4.0 | 3.3 | 30 | ||

34 | 1.2 | 1.1 | 30 | ||

Mobcal | 22 | 29.5 | 24.6 | 30 | |

28 | 5.2 | 3.6 | 30 | ||

34 | 1.3 | 1.0 | 30 | ||

Full HD | Blue_sky | 22 | 13.8 | 11.9 | 30 |

28 | 5.0 | 4.2 | 30 | ||

34 | 2.2 | 2.0 | 30 | ||

Riverbed | 22 | 62.2 | 62.8 | 30 | |

28 | 31.4 | 31.9 | 30 | ||

34 | 15.0 | 14.7 | 30 | ||

Station2 | 22 | 7.3 | 7.4 | 30 | |

28 | 2.3 | 2.5 | 30 | ||

34 | 1.2 | 1.3 | 30 |

**Encoding conditions for test bitstreams**

Profile/level | Main/5.0 |
---|---|

Intra period | 30 |

Search range | 32 |

Search mode | Fast full search |

Coding structure | IPPP/IBBBP |

QP | 22, 28, 34 |

Reference frames | 5 frames |

RD optimization | High complexity mode |

Encoder | JM 17.2 |

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

**Comparison of MCPS and memory requirements for coeff_token syntax element**

Sequences | QP | MCPS | CRR (%) | |||||
---|---|---|---|---|---|---|---|---|

Kim [14] | Iqbal [20] | MTM [21] | Proposed | Kim vs. proposed | Iqbal vs. proposed | MTM vs. proposed | ||

IPPP | IPPP | IPPP | IPPP | IPPP | IPPP | IPPP | ||

IBBBP | IBBBP | IBBBP | IBBBP | IBBBP | IBBBP | IBBBP | ||

Parkrun | 22 | 1,200.8 | 1,159.5 | 1,122.1 | 1,121.6 | 6.6 | 3.3 | 0.0 |

579.5 | 559.2 | 541.0 | 540.7 | 6.7 | 3.3 | 0.0 | ||

28 | 492.3 | 466.7 | 444.9 | 444.4 | 9.7 | 4.8 | 0.1 | |

249.7 | 211.8 | 203.4 | 203.2 | 18.6 | 4.1 | 0.1 | ||

34 | 178.2 | 165.3 | 155.0 | 154.8 | 13.1 | 6.4 | 0.1 | |

84.2 | 79.0 | 74.8 | 74.7 | 11.3 | 5.5 | 0.1 | ||

Shields | 22 | 554.4 | 506.8 | 469.4 | 469.1 | 15.4 | 7.4 | 0.1 |

261.2 | 239.1 | 221.7 | 221.5 | 15.2 | 7.3 | 0.1 | ||

28 | 86.2 | 77.7 | 70.8 | 70.7 | 18.0 | 9.0 | 0.1 | |

35.7 | 32.3 | 29.5 | 29.5 | 17.2 | 8.5 | 0.1 | ||

34 | 23.4 | 20.9 | 18.9 | 18.9 | 19.2 | 9.6 | 0.0 | |

10.5 | 9.4 | 8.5 | 8.5 | 18.8 | 9.4 | −0.1 | ||

Mobcal | 22 | 669.1 | 613.4 | 569.2 | 568.9 | 15.0 | 7.3 | 0.1 |

282.0 | 258.1 | 239.2 | 239.0 | 15.2 | 7.4 | 0.1 | ||

28 | 103.5 | 94.1 | 86.3 | 86.3 | 16.6 | 8.3 | 0.0 | |

36.3 | 33.2 | 30.7 | 30.7 | 15.4 | 7.5 | 0.0 | ||

34 | 20.3 | 18.4 | 16.9 | 17.0 | 16.3 | 7.6 | −0.6 | |

8.9 | 8.1 | 7.5 | 7.5 | 15.9 | 7.6 | 0.0 | ||

Blue_sky | 22 | 347.7 | 311.8 | 283.5 | 283.4 | 18.5 | 9.1 | 0.0 |

143.8 | 129.3 | 117.8 | 117.8 | 18.1 | 8.9 | 0.0 | ||

28 | 124.8 | 110.9 | 99.4 | 99.6 | 20.2 | 10.2 | −0.2 | |

46.0 | 41.0 | 37.0 | 37.0 | 19.6 | 9.8 | −0.1 | ||

34 | 45.2 | 39.9 | 35.6 | 35.8 | 20.8 | 10.3 | −0.6 | |

17.5 | 15.5 | 13.8 | 13.9 | 20.4 | 10.3 | −0.3 | ||

Riverbed | 22 | 1,526.9 | 1,381.1 | 1,274.1 | 1,273.4 | 16.6 | 7.8 | 0.1 |

763.8 | 690.9 | 637.5 | 637.1 | 16.6 | 7.8 | 0.1 | ||

28 | 777.5 | 692.2 | 623.7 | 623.2 | 19.8 | 10.0 | 0.1 | |

390.0 | 347.4 | 313.3 | 313.1 | 19.7 | 9.9 | 0.1 | ||

34 | 324.5 | 287.9 | 256.2 | 256.0 | 21.1 | 11.1 | 0.1 | |

160.1 | 142.1 | 126.5 | 126.5 | 21.0 | 11.0 | 0.1 | ||

Station2 | 22 | 158.4 | 140.6 | 125.9 | 125.9 | 20.5 | 10.5 | 0.0 |

73.6 | 65.4 | 58.6 | 58.6 | 20.4 | 10.4 | 0.0 | ||

28 | 35.5 | 31.5 | 28.0 | 28.0 | 21.1 | 11.1 | 0.0 | |

17.0 | 15.1 | 13.5 | 13.5 | 21.0 | 10.9 | 0.0 | ||

34 | 13.2 | 11.7 | 10.3 | 10.4 | 21.2 | 11.1 | −1.0 | |

6.3 | 5.6 | 5.0 | 5.0 | 21.0 | 10.9 | −0.4 | ||

Average | - | - | - | - | 17.2 | 8.6 | −0.1 | |

- | - | - | - | 17.3 | 8.4 | 0.0 | ||

Required memory (kB) | 0 | 0.718 | 5.968 | 0.718 | - | - | - |

**Comparison of MCPS and memory requirements for level syntax element**

Sequences | QP | MCPS | CRR (%) | |
---|---|---|---|---|

MTM [21] | Proposed | MTM vs. proposed | ||

IPPP | IPPP | IPPP | ||

IBBBP | IBBBP | IBBBP | ||

Parkrun | 22 | 1,146.4 | 1,121.6 | 2.2 |

552.9 | 540.7 | 2.2 | ||

28 | 465.3 | 444.4 | 4.5 | |

210.1 | 203.2 | 3.3 | ||

34 | 167.1 | 154.8 | 7.4 | |

79.4 | 74.7 | 6.0 | ||

Shields | 22 | 517.0 | 469.1 | 9.3 |

243.8 | 221.5 | 9.1 | ||

28 | 79.5 | 70.7 | 11.1 | |

33.0 | 29.5 | 10.5 | ||

34 | 21.6 | 18.9 | 12.3 | |

9.7 | 8.5 | 12.1 | ||

Mobcal | 22 | 624.7 | 568.9 | 8.9 |

262.9 | 239.0 | 9.1 | ||

28 | 95.9 | 86.3 | 10.0 | |

33.8 | 30.7 | 9.0 | ||

34 | 18.9 | 17.0 | 10.5 | |

8.3 | 7.5 | 10.0 | ||

Blue_sky | 22 | 321.3 | 283.4 | 11.8 |

133.3 | 117.8 | 11.6 | ||

28 | 114.9 | 99.6 | 13.3 | |

42.6 | 37.0 | 13.1 | ||

34 | 41.6 | 35.8 | 14.0 | |

16.1 | 13.9 | 13.9 | ||

Riverbed | 22 | 1,429.3 | 1,273.4 | 10.9 |

715.0 | 637.1 | 10.9 | ||

28 | 717.0 | 623.2 | 13.1 | |

360.0 | 313.1 | 13.0 | ||

34 | 296.0 | 256.0 | 13.5 | |

146.5 | 126.5 | 13.7 | ||

Station2 | 22 | 145.2 | 125.9 | 13.3 |

67.6 | 58.6 | 13.3 | ||

28 | 32.5 | 28.0 | 13.7 | |

15.6 | 13.5 | 13.7 | ||

34 | 12.0 | 10.4 | 13.4 | |

5.8 | 5.0 | 13.4 | ||

Average | - | - | 10.7 | |

- | - | 10.4 | ||

Required memory (kB) | 3.5 | 9.937 | - |

**Comparison of MCPS and memory requirements for run_before syntax element**

Sequences | QP | MCPS | CRR (%) | |||
---|---|---|---|---|---|---|

MTM [21] | Kim [14] | Proposed | MTM vs. proposed | Kim vs. proposed | ||

IPPP | IPPP | IPPP | IPPP | IPPP | ||

IBBBP | IBBBP | IBBBP | IBBBP | IBBBP | ||

Parkrun | 22 | 1,284.9 | 1,259.0 | 1,121.6 | 12.7 | 10.9 |

614.6 | 604.3 | 540.7 | 12.0 | 10.5 | ||

28 | 504.3 | 492.9 | 444.4 | 11.9 | 9.8 | |

228.8 | 225.0 | 203.2 | 11.2 | 9.7 | ||

34 | 175.0 | 171.1 | 154.8 | 11.6 | 9.5 | |

84.3 | 82.7 | 74.7 | 11.4 | 9.7 | ||

Shields | 22 | 529.4 | 514.6 | 469.1 | 11.4 | 8.8 |

249.6 | 243.0 | 221.5 | 11.3 | 8.8 | ||

28 | 76.1 | 74.7 | 70.7 | 7.1 | 5.3 | |

31.9 | 31.3 | 29.5 | 7.3 | 5.7 | ||

34 | 19.9 | 19.6 | 18.9 | 5.1 | 3.7 | |

9.0 | 8.9 | 8.5 | 5.1 | 3.9 | ||

Mobcal | 22 | 644.2 | 626.7 | 568.9 | 11.7 | 9.2 |

269.6 | 262.5 | 239.0 | 11.3 | 8.9 | ||

28 | 94.0 | 92.1 | 86.3 | 8.2 | 6.3 | |

33.5 | 32.9 | 30.7 | 8.3 | 6.7 | ||

34 | 18.3 | 18.0 | 17.0 | 7.3 | 6.0 | |

8.1 | 8.0 | 7.5 | 7.7 | 6.4 | ||

Blue_sky | 22 | 304.5 | 297.6 | 283.4 | 6.9 | 4.8 |

126.1 | 123.6 | 117.8 | 6.6 | 4.7 | ||

28 | 103.5 | 102.1 | 99.6 | 3.8 | 2.4 | |

38.6 | 38.1 | 37.0 | 4.2 | 2.8 | ||

34 | 36.8 | 36.4 | 35.8 | 2.7 | 1.6 | |

14.3 | 14.2 | 13.9 | 3.0 | 1.9 | ||

Riverbed | 22 | 1,361.2 | 1,339.0 | 1,273.4 | 6.4 | 4.9 |

680.8 | 669.8 | 637.1 | 6.4 | 4.9 | ||

28 | 650.2 | 638.2 | 623.2 | 4.2 | 2.4 | |

326.8 | 320.7 | 313.1 | 4.2 | 2.4 | ||

34 | 263.9 | 260.1 | 256.0 | 3.0 | 1.6 | |

130.3 | 128.3 | 126.5 | 2.9 | 1.5 | ||

Station2 | 22 | 130.8 | 129.0 | 125.9 | 3.8 | 2.4 |

60.9 | 60.1 | 58.6 | 3.7 | 2.4 | ||

28 | 28.7 | 28.5 | 28.0 | 2.4 | 1.7 | |

13.8 | 13.7 | 13.5 | 2.5 | 1.8 | ||

34 | 10.7 | 10.6 | 10.4 | 2.6 | 1.8 | |

5.1 | 5.1 | 5.0 | 2.6 | 1.8 | ||

Average | - | - | - | 6.8 | 5.2 | |

- | - | - | 6.8 | 5.3 | ||

Required memory (kB) | 0.57 | 0 | 2.109 | - | - |

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.

**Comparison of MCPS for CAVLD**

Sequences | QP | MCPS | CRR (%) | ||||
---|---|---|---|---|---|---|---|

FFmpeg [22] | FFmpeg
| Proposed | FFmpeg vs. FFmpeg
| FFmpeg vs. proposed | FFmpeg
| ||

IPPP | IPPP | IPPP | IPPP | IPPP | IPPP | ||

IBBBP | IBBBP | IBBBP | IBBBP | IBBBP | IBBBP | ||

Parkrun | 22 | 1,971.0 | 1,250.6 | 1,121.6 | 36.6 | 43.1 | 10.3 |

944.7 | 598.9 | 540.7 | 36.6 | 42.8 | 9.7 | ||

28 | 802.3 | 504.5 | 444.4 | 37.1 | 44.6 | 11.9 | |

358.2 | 226.3 | 203.2 | 36.8 | 43.3 | 10.2 | ||

34 | 285.4 | 179.1 | 154.8 | 37.2 | 45.8 | 13.6 | |

134.5 | 84.9 | 74.7 | 36.9 | 44.5 | 12.1 | ||

Shields | 22 | 893.7 | 554.2 | 469.1 | 38.0 | 47.5 | 15.4 |

420.7 | 261.0 | 221.5 | 38.0 | 47.3 | 15.1 | ||

28 | 134.0 | 82.4 | 70.7 | 38.5 | 47.2 | 14.2 | |

55.3 | 34.1 | 29.5 | 38.3 | 46.6 | 13.5 | ||

34 | 35.7 | 21.9 | 18.9 | 38.7 | 47.1 | 13.7 | |

15.9 | 9.8 | 8.5 | 38.4 | 46.5 | 13.1 | ||

Mobcal | 22 | 1,082.3 | 672.2 | 568.9 | 37.9 | 47.4 | 15.4 |

455.4 | 282.3 | 239.0 | 38.0 | 47.5 | 15.3 | ||

28 | 163.1 | 100.5 | 86.3 | 38.3 | 47.1 | 14.2 | |

57.2 | 35.4 | 30.7 | 38.1 | 46.3 | 13.2 | ||

34 | 31.4 | 19.5 | 17.0 | 38.1 | 46.1 | 12.9 | |

13.7 | 8.5 | 7.5 | 37.8 | 45.5 | 12.3 | ||

Blue_sky | 22 | 538.5 | 331.0 | 283.4 | 38.5 | 47.4 | 14.4 |

221.4 | 136.6 | 117.8 | 38.3 | 46.8 | 13.7 | ||

28 | 188.4 | 115.4 | 99.6 | 38.7 | 47.2 | 13.7 | |

69.4 | 42.7 | 37.0 | 38.5 | 46.6 | 13.3 | ||

34 | 68.3 | 41.4 | 35.8 | 39.3 | 47.6 | 13.6 | |

26.3 | 16.1 | 13.9 | 39.0 | 47.2 | 13.4 | ||

Riverbed | 22 | 2,313.6 | 1,438.6 | 1,273.4 | 37.8 | 45.0 | 11.5 |

1,156.8 | 719.4 | 637.1 | 37.8 | 44.9 | 11.4 | ||

28 | 1,171.3 | 716.7 | 623.2 | 38.8 | 46.8 | 13.0 | |

588.2 | 359.7 | 313.1 | 38.8 | 46.8 | 13.0 | ||

34 | 484.4 | 297.0 | 256.0 | 38.7 | 47.2 | 13.8 | |

240.0 | 146.5 | 126.5 | 38.9 | 47.3 | 13.7 | ||

Station2 | 22 | 242.7 | 146.9 | 125.9 | 39.5 | 48.1 | 14.3 |

112.9 | 68.3 | 58.6 | 39.5 | 48.1 | 14.1 | ||

28 | 53.3 | 32.5 | 28.0 | 39.0 | 47.4 | 13.8 | |

25.5 | 15.6 | 13.5 | 38.9 | 47.3 | 13.7 | ||

34 | 19.6 | 12.1 | 10.4 | 38.5 | 47.0 | 13.9 | |

9.4 | 5.8 | 5.0 | 38.5 | 47.0 | 13.8 | ||

Average | - | - | - | 38.3 | 46.6 | 13.5 | |

- | - | - | 38.2 | 46.2 | 13.0 | ||

Required memory (kB) | 73.6 | 73.6 | 30.1 | - | - | - |

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

## Declarations

## Authors’ Affiliations

## References

- ITU-T:
*Advanced video coding for generic audiovisual services,” Recommendation ITU-T H.264*. Geneva: ITU; 2012.Google Scholar - Ku WC, Chou SH, Chu JC, Liu CL, Chen TF, Guo JI, Wang JS: VisoMT: a collaborative multithreading multicore processor for multimedia applications with a fast data switching mechanism.
*IEEE Trans Circuit Syst Video Tech*2009, 19(11):1633-1645.View ArticleGoogle Scholar - Chen YK, Tian X, Ge S, Girkar M: Towards efficient multi-level threading of H.264 encoder on Intel hyper-threading architectures. In
*Parallel and Distributed Processing Symposium*. Santa Fe, New Mexico; 2004:63-72.Google Scholar - Meenderinck C, Azevedo A, Juurlink B, Mesa MA, Ramirez A: Parallel scalability of video decoders.
*J Signal Process Syst*2008, 57(2):173-194.View ArticleGoogle Scholar - Li P, Veeravalli B, Kassim AA: Design and implementation of parallel video encoding strategies using divisible load analysis.
*IEEE Trans Circ Syst Video Tech*2005, 15(9):1098-1112.View ArticleGoogle Scholar - Yu W, He Y: A high performance CABAC decoding architecture.
*IEEE Trans Consum Electron*2005, 51(4):1352-1359. 10.1109/TCE.2005.1561867View ArticleGoogle Scholar - Yi Y, Park IC: High-speed H.264/AVC CABAC decoding.
*IEEE Trans Circ Syst Video Tech*2007, 17(4):490-494.View ArticleGoogle Scholar - Osorio RR, Bruguera JD: High-throughput architecture for H.264/AVC CABAC compression system.
*IEEE Trans Circ Syst Video Tech*2006, 16(11):1376-1384.View ArticleGoogle Scholar - Lin H, Lu Y, Liu B, Yang J: A highly efficient VLSI architecture for H.264/AVC CAVLC decoder.
*IEEE Trans Multimed*2008, 10(1):31-42.View ArticleGoogle Scholar - Lee GG, Lo C-C, Chen Y-C, Lin H-Y, Wang M-J: High-throughput low-cost VLSI architecture for AVC/H.264 CAVLC decoding.
*IET Image Process*2010, 4(2):81-91. 10.1049/iet-ipr.2008.0064View ArticleGoogle Scholar - Tsai TH, Fang TL, Pan YN: A novel design of CAVLC decoder with low power and high throughput considerations.
*IEEE Trans Circ Syst Video Technol*2011, 21(3):311-319.View ArticleGoogle Scholar - JM software . Accessed 4 March 2013 http://iphome.hhi.de/suehring/tml/download
- Moon YH, Kim GY, Kim JH: An efficient decoding of CAVLC in H.264/AVC video coding standard.
*IEEE Trans Consum Electron*2005, 51(3):933-938. 10.1109/TCE.2005.1510506View ArticleGoogle Scholar - Kim YH, Yoo YJ, Shin J, Choi B, Paik J: Memory-efficient H.264/AVC CAVLC for fast decoding.
*IEEE Trans Consum Electron*2005, 52(3):943-952.Google Scholar - Rivera F, Sanchez-Elez M, Fernandez M, Bagherzadeh N: An approach to execute conditional branches onto SIMD multi-context reconfigurable architectures. In
*IEEE Proceedings of the DSD*. Porto; 396-402. 30 August - 3 September 2005Google Scholar - Lee JS, Jeong JH, Chang TG: An efficient method of Huffman decoding for MPEG-2 AAC and its performance analysis.
*IEEE Trans Speech Audio Process*2005, 13(6):1206-1209.View ArticleGoogle Scholar - Hashemian R: Memory efficient and high-speed search Huffman coding.
*IEEE Trans Comm*1995, 43(10):2576-2581. 10.1109/26.469442View ArticleGoogle Scholar - Choi SB, Lee MH: High speed pattern matching for a fast Huffman decoder.
*IEEE Trans Consum Electron*1995, 41(1):97-103. 10.1109/30.370315View ArticleGoogle Scholar - Wang SW, Wu JL, Chuang SC, Hsiao CC, Tung YS: Memory efficient hierarchical lookup tables for mass arbitrary-side growing Huffman trees decoding.
*IEEE Trans Circ Syst Video Tech*2008, 18(10):1335-1346.View ArticleGoogle Scholar - Iqbal N, Henkel J: Efficient constant-time entropy decoding for H.264. In
*Design, Automation and Test in Europe Conference and Exhibition*. Nice; 1440-1445. 20–24 April 2009Google Scholar - Gue H, Xia X, Sun W, Zhou J, Yu S: An memory-efficient variable length decoding scheme for embedded MPEG-4 video decoders. In
*ICSP 2006 Proceedings of IEEE*. Beijing, China; 2006. 16–20 Nov 2006Google Scholar - FFMPEG 2013.http://ffmpeg.org/index.html
- Lee WJ, Woo SO, Kwon KT, Son SJ, Min KJ, Jang GJ, Lee CH, Jung SY, Park CM, Lee SH: A scalable GPU architecture based on dynamically reconfigurable embedded processor. In
*High Performance Graphics*. Vancouver; 5–7 August 2011Google Scholar - Mei B, Lambrechts A, Verkest D, Mignolet JY, Lauwereins R: Architecture exploration for a reconfigurable architecture template.
*IEEE Des Test Comput*2005, 22(2):90-101. 10.1109/MDT.2005.27View ArticleGoogle Scholar - Furber S: ARM System-On-Chip Architecture. 2nd edition. Boston: Addison-Wesley; 39-42.Google Scholar

## Copyright

This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.