• 沒有找到結果。

Chapter 2 Algorithm of CABAD for H.264/AVC

2.3 Binarization decoding flow

In Section 2.3, we focus on the decoding process of the binarization. It reads the bin string to look up the suitable syntax elements. For H.264/AVC, CABAD adopts five kinds of the binarization methods to decode all syntax elements. This section is organized as follows. In Section 2.3.1, the decoding flow of the unary code is shown at the first. The unary code is the basic coding method. Section 2.3.2 shows the truncated unary code which is the advanced unary coding method. It is applied in order to save the unary bit to express the current value. In Section 2.3.3, we introduce the fixed-length decoding flow. It is the typical binary integer method. Section 2.3.4 is the Exp-Golomb decoding flow. The Exp-Golomb decoding flow is only used for the residual data and the motion vector difference (mvd). Section 2.3.5 is the special definition by means of the table method. Specifically, we focus on the binary tree of the macroblock type (mb_type) and the sub-macroblock type (sub_mb_type).

2.3.1 Unary decoding flow (U)

Table 1 is the format of the typical unary code. If the syntax element is equal to

“0”, the bin outputs single bit “0”. Besides the syntax element “0”, the bin string sends numSE “1” and one “0” in the end of the binary value. The value of numSE is equal to the syntax element. We find, therefore, the string length of the current syntax element bin string is numSE+1.

According to the unary bin string format shown above, we arrange the decoding algorithm in Eq. 6. This equation represents the pseudo code of the unary decoding flow. It sets binIdx to zero at the initial step where binIdx is the index of the bin string in Table 1. The while loop in Eq. 6 checks the current bin assigned by binIdx from the

equal to “0”, the binarization process arrives at the end of decoding step. binIdx sends to SEVal which is defined as the value of the syntax element.

Table 1 bin string of the unary code [1]

Syntax

element bin string

0 0

Start unary decoder process binIdx = 0 ;

while (bin[binIdx] == 1){

binIdx = binIdx + 1 ; }

SEVal = binIdx ; (Eq. 6)

2.3.2 Truncated unary decoding flow (TU)

The truncated unary decoding flow is based on the unary one and has an additional factor of cMax which is defined as the maximum length of the current bin string. If the value of syntax element (SEVal) is less than cMax, the truncated unary and the typical unary decoding flow are the same. If SEVal is equal to cMax, the number “1” of the bin string is equal to cMax and there is no “0” bit in the current string. For example, SEVal (=“3”) is assumed. If the value of cMax is “4”, the result of bin string is equal to “1110”. If the value of cMax is “3”, the result of bin string is equal to “111” where the end bit of “0” is truncated in this case.

Start unary decoder process binIdx = 0 ;

while (bin[binIdx] == 1 && (binIdx<cMax)){

binIdx = binIdx + 1 ; }

SEVal = binIdx ; (Eq. 7)

Eq. 7 is the truncated unary decoding flow which is modified from Eq. 6.

Besides checking the bin value, it also deals with cMax. If binIdx is less than cMax, it works the unary decoding flow. If binIdx isn’t less than cMax, it completes the decoding action until reading the end bin of “0” bit.

2.3.3 Fixed-length decoding flow (FL)

The fixed-length code is the simple-defined format of the binarization decoding process which is defined as the typical unsigned integer. The coding rule is represented by means of the typical binary number. For example, the value of “410” is equal to “1002”. The value of “410” is defined as the decimal style and the value of

“1002” is the binary format which is the required fixed-length code.

Table 2 bin string of the fixed-length code Syntax

element bin string

0 0 0 0 0 0 0

The fixed-length decoding flow has to refer to the value of cMax which defines the number size of the current syntax element. Table 2 shows the fixed-length code definition. In this table, the cMax equals five because the maximum value of binIdx is five. All syntax elements which are decoded by the fixed-length format are always represented with six binary bits.

2.3.4 Unary/k-th order Exp-Golomb decoding flow (UEGk)

The unary/k-th order Exp-Golomb (UEGk) code is composed of two parts which are the prefix and suffix ones. The prefix part of UEGk is specified by using the truncated unary code. So the prefix part is dominated by cMax. The suffix part of this code doesn’t always apply because isn’t adopted by two cases. Both cases check the value of the provided signedValFlag and the bin string. If signedValFlag is equal to

“1” and the prefix bin contains only one “0” bit, the value of syntax element is just decided by prefix bin string with the truncated unary code. If signedValFlag is equal to “0” and the prefix bin string isn’t equal to the bit string which is composed of the string length cMax of bit “1”, the decoding flow doesn’t also enter the suffix decoding step. Besides these two cases, the decoding process has to go to the suffix decoding.

Eq 8 shows the suffix part algorithm by means of the pseudo code. The initial value of k is defined as the order of the unary Exp-Golomb coding which are named as UEGk. In the binarization decoding engine of CABAD, it only applies two decoding flows such as UEG0 and UEG3. UEG0 is used by the residual data decoding process and UEG3 is used by the motion vector difference one.

if( Abs( synElVal ) >= uCoff ) {

2.3.5 Special decoding flow

All formats of the binarization decoding process are introduced above. But there is still a special decoding flow which we don’t describe yet. In order to perform the higher video quality, the macroblock and sub-macroblock are divided into many kinds of types such as I, P, B, and SI slices. In the four basic types, it also sorts by variable block sizes. These two syntax elements are difficult to define by means of the aforementioned decoding flows. In H.264/AVC, it adopts the table-based method to define the macro and sub-macroblock types.

Table 9-26 and Table 9-27 in the standard [1] show the macroblock types in I, SI, P, SP, and B slices. Table 9-28 in th standard [1] shows the sub-macroblock types in P, SP, and B slices. The binarization engine reads the bin string and checks if the bin string is mapped the specified location in these table. If the assigned bin string is found in the tables, it can look up the current macroblock type. We observe that the probability of the macroblock type appearance is larger and the described bin string is shorter. For example, if the value of bin string is equal to”100001” in I slice, the mapped macroblock type is equal to “2” by looking up Table 9-27 of the standard [1].

The macroblock in SI slice is the enhanced format of the macroblock type in I slice. The bin string of the SI slice macroblock type is composed of two parts: prefix bit and the suffix part. If the prefix bit is equal to “0”, it doesn’t need the suffix part and the syntax element is equal to “0”. If the prefix bit is equal to “1”, the suffix part is defined in Table9-27 of the standard [1] which mapped value of the macroblock type has to be added by “1” in SI slice.

Besides the macroblock type in SI slice, there are still two cases to process the bin value through the suffix. Table 9-27 of the standard [1] is the prefix definitions of mbType. The suffix parts are decoded by the formats in Table 9-26 of the standard [1]

because these fields are the intra macroblock type in P, SP, and B slice. But the value

of the macroblock type in the last fields in P and B slice have to be added by the offset value. In the P and SP slices, the value of mbType is equal to the summation of the offset value “5” through Table 9-27 in the standard [1] and the bin string assignment in Table 9-26 of the standard [1] if the prefix bit is equal to “1”. In the B slices, the value of mbType is equal to the summation of the offset value “23” through Table 9-27 in the standard [1] and the bin string assignment in Table 9-26 of the standard [1] if the prefix bin string is equal to “111101”.

相關文件