Huffman Coding Author: Latha Pillai

Transcription

1 Application Note: Virtex Series XAPP616 (v1.0) April 22, 2003 R Huffman Coding Author: Latha Pillai Summary Huffman coding is used to code values statistically according to their probability of occurence. Short code words are assigned to highly probable values and long code words to less probable values. Huffman coding is used in MPEG-2 to further compress the bitstream. This application note describes how Huffman coding is done in MPEG-2 and its implementation. Introduction The output symbols from RLE are assigned binary code words depending on the statistics of the symbol. Frequently occurring symbols are assigned short code words whereas rarely occurring symbols are assigned long code words. The resulting code string can be uniquely decoded to get the original output of the run length encoder. The code assignment procedure developed by Huffman is used to get the optimum code word assignment for a set of input symbols. The procedure for Huffman coding involves the pairing of symbols. The input symbols are written out in the order of decreasing probability. The symbol with the highest probability is written at the top, the least probability is written down last. The least two probabilities are then paired and added. A new probability list is then formed with one entry as the previously added pair. The least symbols in the new list are then paired. This process is continued till the list consists of only one probability value. The values "0" and "1" are arbitrarily assigned to each element in each of the lists. Figure 1 shows the following symbols listed with a probability of occurrence where: A is 30%, B is 25%, C is 20%, D is 15%, and E = 10%. A B C D E A G B A F B C Figure 1: Huffman Coding Procedure H G x616_01_ Step 1. Adding the two least probable symbols gives 25%. The new symbol is F 2. Adding the two least probable symbols gives 45%. The new symbol is G 3. Adding the two least probable symbols gives 55%. The new symbol is H 4. Write "0" and "1" on each branch of the summation arrows. These binary values are called branch binaries Xilinx, Inc. All rights reserved. All Xilinx trademarks, registered trademarks, patents, and further disclaimers are as listed at All other trademarks and registered trademarks are the property of their respective owners. All specifications are subject to change without notice. NOTICE OF DISCLAIMER: Xilinx is providing this design, code, or information "as is." By providing the design, code, or information as one possible implementation of this feature, application, or standard, Xilinx makes no representation that this implementation is free from any claims of infringement. You are responsible for obtaining any rights you may require for your implementation. Xilinx expressly disclaims any warranty whatsoever with respect to the adequacy of the implementation, including but not limited to any warranties or representations that this implementation is free from claims of infringement and any implied warranties of merchantability or fitness for a particular purpose. XAPP616 (v1.0) April 22,

2 R Huffman Coding in MPEG-2 5. For each letter in each column, copy the binary numbers from the column on the right, starting from the right most column (i.e., in column three, G gets the value "1" from the G in column four.) For summation branches, append the binary from the right-hand side column to the left of each branch binary. For A and C in column three append "0" from H in column four to the left of the branch binaries. This makes A "00" and B "01". Completing step 5 gives the binary values for each letter: A is "00", B is "01", C is "11", D is "100", and E is "101". The input with the highest probability is represented by a code word of length two, whereas the lowest probability is represented by a code word of length three. Huffman Coding in MPEG-2 Encoding MPEG is a non-adaptive coding system, the code table does not change with the input video sequence. Many image sequences were coded and the statistics used to define the entries in the MPEG-2 Huffman table. JPEG still image compression, using adaptive entropy coding, where the table entries can be modified to better suit a particular picture. JPEG also uses adaptive arithmetic coding where the code table is changeable depending on the change in the statistics of the JPEG image. MPEG defines a set of variable-length code (VLC) for each of the probable run/level combinations. The run/level combinations not found in the table are represented by an escape code followed by a six-bit code for the run and an eight or 16-bit code for the level. The end-ofblock (EOB) code is used when all the remaining coefficients in the 8 x 8 block are zeroes. Coding of the 8 x 8 block starts from the DC coefficient in the zigzag order. When there are no more nonzero coefficients remaining in the zigzag order, the EOB code is used to terminate coding. Since the probability of occurrence of the EOB symbol is high, it is assigned a two-bit code "10". The VLC tables used in MPEG-2 are not true Huffman codes. They are optimized for a range of bit rates to sample rate ratios. Most of the code words in the MPEG-2 tables were carried over from the H.261 standard. The DCT coefficient tables in MPEG-2 assume equal probability for both positive and negative coefficients. MPEG-2 VLC uses a new table, Table 8. It is better suited for the statistics of intra-coded blocks. The EOB code for Table 7 has two bits but for Table 8, the EOB has four bits. This implies that an intra-coded block can have on average of 2 4 or 16 non-zero AC coefficients. For non intra-coded blocks, the statistics point to an average of 2 2 or four non-zero AC coefficients. Both Table 7 and Table 8 have 113 entries. The VLC table consists of Huffman codes for different run/level combinations. The last bit "s" of the code denotes the sign of the level with s = 0 for positive and s = 1 for negative. The VLC table also includes the EOB code to indicate the status of the rest of the coefficients as zero. The EOB cannot occur as the only code in a block since no coding was done in the block. There are run/level combinations not defined in the VLC tables. When the variable length coder sees an undefined run/level combination, it codes the run into a 6-bit binary value and the level into a 12-bit signed level value. Before coding an undefined run/level pair, a 6-bit "escape code" is used to denote that the next six to12 bits are not from the VLC table. DC Coefficients Due to high redundancy between adjacent quantized DC coefficients of 8 x 8 blocks, the difference in DC values is encoded using VLC. The difference signals range from 255 to 255 in MPEG-1 and from 2047 to 2047 in MPEG-2. The size of the differential DC value (dct_dc_size) is found in Table 1. The size denotes the number of bits used to represent a particular value (e.g., if the differential DC value is 78, the table shows a size seven. The seven bits will be used to represent the value 78. The dct_dc_size value is variable length coded using table Table 5 or Table 6. After coding the size bits, 78 is represented as , where the first six bits define the dct_dc_size and the next seven bits are used to code the value 78. Two different VLC codes are used for coding the dct_dc_size for luma and chroma. 2 XAPP616 (v1.0) April 22, 2003

3 Encoding R The difference path for 8 x 8 blocks within a macroblock are calculated in the order shown in Figure MB1 MB2 x616_02_ Figure 2: Calculation Order in Adjacent Macroblocks Table 1: Differential DC Additional Codes Differential DC Size Additional Code 2047 to to to to to to to to to to to to to to to to to to to to to to 11 4 to to to to to to to to to to to to to to to to to to XAPP616 (v1.0) April 22,

4 R Decoding AC Coefficients The Huffman tables used for coding AC coefficients are selected based on the macroblock type and intra_vlc_format value according to Table 2. For MPEG-1 coding, only Table 7 is used. For MPEG-2, Table 8 is used for intra-coded blocks and Table 7 for non-intra coded blocks. In Table 7, there are two Huffman codes for the run/level combination of 0/1. The code "1s" is used if the 0/1 pair represents the first coefficient or the DC coefficient in the block. For subsequent 0/1 run/level pairs, "11s" is used as the Huffman code. The "s" in the code denotes the sign of the coefficient, "0" for positive and "1" for negative. The run/level pair for DC coefficient of "+1" and the EOB code has the same Huffman code. The differentiation is apparent since the EOB code will not be the first code in the block. In intra coding, since the DC value is coded separately, the first coded symbol is the first AC value. In this case, this first coded value can have a run/level of 0/1. A Huffman code of "11s" will not conflict with the EOB symbol. For a run/level pair that is not defined in the VLC Table 7 and Table 8, an escape code is used according to Table 9, followed by a 6-bit run symbol and 12-bit level symbol. Table 2: Selection of DCT Coefficient VLC Tables intra_vlc_format 0 1 intra coded blocks (macroblock_intra = 1) non-intra coded blocks (macroblock_intra = 0) Reference Table 7 Reference Table 8 Reference Table 7 Reference Table 7 Notes: 1. This table was taken from ISO/IEC : 1995 (E), Table 7-3. Table 7 and Table 8 are stored in ROMs. The run/level value is used to access the ROM and the corresponding variable length code is read out. Decoding DC Coefficient Three predictor values are maintained for each color component. The predictor values are set at the start of the slice, or when a non-intra macroblock is decoded, or when a macroblock is skipped. The predictor values for different intra_dc_precisions are shown in Table 3. Table 3: Relationship Between intra_dc_precision and the Predictor Reset Value intra_dc_precision Bits of Precision Reset Value Notes: 1. This table was taken from ISO/IEC : 1995 (E), Table 7-2. (Reference Item 1) The DC coefficient is decoded by first getting the differential value from the coded stream. This differential_dc value is then added to the predictor to get the actual DC value. The new predictor value then becomes the actual DC value just decoded. The decoding process can be described in the following manner (from ISO/IEC : 1995 (E) (Reference Item 1) ) 4 XAPP616 (v1.0) April 22, 2003

5 Decoding R QFS[0] shall be calculated from dc_dct_size and dc_dct_differential by any process equivalent to: if ( dc_dct_size == 0 ) { dct_diff = 0; } else { half_range = 2 ^ ( dc_dct_size - 1 ); Note ^ denotes power (not XOR) if ( dc_dct_differential >= half_range ) dct_diff = dc_dct_differential; else dct_diff = (dc_dct_differential + 1) - (2 * half_range); } QFS[0] = dc_dct_pred[cc] + dct_diff; dc_dct_pred[cc] = QFS[0] Note: dct_diff and half_range are temporary variables that are not used elsewhere in this specification. It is a requirement of the bitstream that QFS[0] shall lie in the range of zero to 8 intra dc precision ( 2 + ) 1 AC Coefficient The run/level pair is decoded from the Huffman code using a look-up table (LUT). There are three possible options for the Huffman code. If the code represents an EOB, all the remaining coefficients are set to "0". If the code represents an escape code, the next six bits represent the run and the following 12 bits represent the level. If the VLC denotes a normal coefficient, then the run coefficients are set to zero and the following level coefficient is set to the level value depending on the value of s. When s == 0, the signed level is the same as level. When s == 1, the signed level is equal to ( level). XAPP616 (v1.0) April 22,

6 R Huffman Implementation Huffman Implementation The run/length pair is mapped to variable length codes from the code table. The code words are concatenated together and the output is partitioned into fixed length segments. The implementation shown in Figure 3 is similar to the one proposed by Lei and Sun (Reference Item 2). (code_length + cl_sum_prev) mux input s u b a d d cl_sum_prev in1 32 cl_sum_prev half_flag HF full_flag FF cl_sum cl_sum_shift Barrel Shifter [38:0] Upper[16:1] Huffman_out dc_in rl_in R1 size scan_type luma vlcode_dc vodelength_dc vlcode_ac vodelength_ac Pipeline Matching code_length vl_code cntr64 (1, 1) Middle[16:1] Lower[16:1] f h u a l l l f f f l l a a g g F F F F x616_03_ Figure 3: Huffman Implementation Block Diagram 6 XAPP616 (v1.0) April 22, 2003

7 Huffman Implementation R Huffman Implementation Results Table 4: Huffman Implementation Results by Device Type Device Post-Route (Synthesis Constraint) LUTs and Flip Flops XCV300E -8 BG (100 MHz) 785 LUTs 340 FFs XCV300-6 PQ (100 MHz) 777 LUTs 340 FFs XC2S200-6 FG (100 MHz) 777 LUTs 340 FFs Figure 4: Input "rl-in" to the Huffman Coder x616_04_ Figure 5: Output "Huffman-out" from the Huffman Coder x616_05_ XAPP616 (v1.0) April 22,

8 R Conclusion The performance can be improved by adding more pipeline stages in the designs. Keep the place and route effort level on "High". To get an update on performance and utilization, always re-run the designs using the latest Xilinx software. Reference Design A Huffman implementation reference design in both VHDL and Verilog is available on the Xilinx FTP site at: ftp://ftp.xilinx.com/pub/applications/xapp/xapp616.zip Conclusion This Huffman coding application note describes the Huffman coding algorithms used in an MPEG-2 encoder. The design uses the Huffman table described in the MPEG-2 ISO/IEC :1995 (E) document. The reference design files show the efficient implementation of the algorithms on Xilinx devices. The code can be used to target any Xilinx device. The code can be optimized by instantiating the adder/subtractor and multiplier units when targeting Virtex devices. Adding more pipeline stages can increase the performance of both blocks. The code takes in variable length data and sends out a fixed length (16-bit) Huffman coded data. References 1. MPEG-2 Video IS document, ISO/IEC : 1995(E) 2. Lei and Sun. An entropy coding system for digital HDTV applications. IEEE Transactions on Circuits and Systems for Video Technology, 1(1): , March Image and Video Compression Standards, Second Edition, by Vasudev Bhaskaran and Konstantinos Konstantinides, ISBN MPEG Video Compression Standard, by Mitchell, Pennebaker, Fogg, and LeGall, ISBN Appendix A The following tables are referenced in this application note. Table 5: Variable Length Codes for dct_dc_size_luminance Variable Length Code dct_dc_size_luminance Notes: 1. This table is taken from Table B-12, ISO/IEC : 1995(E) 8 XAPP616 (v1.0) April 22, 2003

9 Appendix A R Table 6: Variable Length Codes for dct_dc_size_chrominance Variable Length Code dct_dc_size_chrominance Notes: 1. This table is taken from Table B-13, ISO/IEC : 1995(E) Table 7: DCT Coefficients Table Zero Variable Length Code (Note 1) Run Level 10 (Note 2) End of Block 1 s (Note 3) s (Note 4) s s s s s s s s s s s s s s s Escape XAPP616 (v1.0) April 22,

10 R Appendix A Table 7: DCT Coefficients Table Zero (Continued) Variable Length Code (Note 1) Run Level s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s XAPP616 (v1.0) April 22, 2003

11 Appendix A R Table 7: DCT Coefficients Table Zero (Continued) Variable Length Code (Note 1) Run Level s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s 0 35 XAPP616 (v1.0) April 22,

12 R Appendix A Table 7: DCT Coefficients Table Zero (Continued) Variable Length Code (Note 1) Run Level s s s s s s s s s s s s s s s s s s s s s s s s s s s s 31 1 Notes: 1. The last bit "s" denotes the sign of the level, "0" for positive "1" for negative. 2. "End of Block" shall not be the only code of the block. 3. This code shall be used for the first (DC) coefficient in the block 4. This code shall be used for all other coefficients 5. This table is taken from Table B-14, ISO/IEC : 1995(E) 12 XAPP616 (v1.0) April 22, 2003

13 Appendix A R Table 8: DCT Coefficients Table One Variable Length Code (Note 1) Run Level 0110 (Note 2) End of Block 10 s s s s s s s s s s s s s s s Escape s s s s s s s s s s s s s s s s 16 1 XAPP616 (v1.0) April 22,

14 R Appendix A Table 8: DCT Coefficients Table One (Continued) Variable Length Code (Note 1) Run Level s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s XAPP616 (v1.0) April 22, 2003

15 Appendix A R Table 8: DCT Coefficients Table One (Continued) Variable Length Code (Note 1) Run Level s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s 6 3 XAPP616 (v1.0) April 22,

16 R Revision History Table 8: DCT Coefficients Table One (Continued) Variable Length Code (Note 1) Run Level s s s s s s s s s s s 31 1 Notes: 1. The last bit "s" denotes the sign of the level, "0" for positive "1" for negative. 2. "End of Block" is not the only code of the block. 3. This code is used for the first (DC) coefficient in the block 4. This code is used for all other coefficients 5. This table is taken from Table B-15, ISO/IEC : 1995(E) Table 9: Encoding of Run and Level Following an Escape Code Fixed Length Code Run Fixed Length Code Signed Level forbidden Notes: 1. This table is taken from Table B-16, ISO/IEC : 1995(E) Revision History The following table shows the revision history for this document. Date Version Revision 04/22/ Initial Xilinx release XAPP616 (v1.0) April 22, 2003