GB2483319A - Huffman decoder using modified Huffman Code Table - Google Patents

Huffman decoder using modified Huffman Code Table Download PDF

Info

Publication number
GB2483319A
GB2483319A GB1101178.0A GB201101178A GB2483319A GB 2483319 A GB2483319 A GB 2483319A GB 201101178 A GB201101178 A GB 201101178A GB 2483319 A GB2483319 A GB 2483319A
Authority
GB
United Kingdom
Prior art keywords
hct
sub
codes
lut
band
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
GB1101178.0A
Other versions
GB201101178D0 (en
Inventor
Mingying Lu
Guoyu Wang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Publication of GB201101178D0 publication Critical patent/GB201101178D0/en
Publication of GB2483319A publication Critical patent/GB2483319A/en
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
    • H03M7/4031—Fixed length to variable length coding
    • H03M7/4037—Prefix coding
    • H03M7/4043—Adaptive prefix coding
    • H03M7/4062—Coding table adaptation
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
    • H03M7/42—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code using table look-up for the coding or decoding process, e.g. using read-only memory
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
    • H03M7/42—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code using table look-up for the coding or decoding process, e.g. using read-only memory
    • H03M7/425—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code using table look-up for the coding or decoding process, e.g. using read-only memory for the decoding process only
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/60—General implementation details not specific to a particular type of compression
    • H03M7/6017—Methods or arrangements to increase the throughput
    • H03M7/6023—Parallelization

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)

Abstract

This invention proposes a Huffman Code Table (HCT) transform and a parallel Huffman decoding method based on this transformed HCT. The transformation of the HCT reorders the rows of the original HCT so that the codes are arranged in an ascending or descending order, and partitions it into a number of sub-bands, each respective sub-band containing codes of the same length. Two kinds of modification, namely bit removal or bit stuffing, may also be made to the reordered codes in the HCT in order to reduce the number of sub-bands of the reordered HCT. Incoming data is compared to threshold values for each sub-band to determine the correct sub-band for the data, and the correct entry for the incoming data is then found using the sub-band number and an offset code in each sub-band.

Description

Huffman Code Table Transform for Parallel Decoding
Description of the Invention
Technical Field
The Huffman coding method has been widely used in data compression for digital audio, image and video technology to reduce data transmission requirements.
Especially in HD TV or mobile TV a very high data compression rate is required.
Therefore faster and simpler Huffman decoding becomes a critical technique for implementing modern digital audio/video technology.
Conventional lluffman Decoding Methods The simplest method of decoding a Huffman coded stream is to walk a binary tree, created from the HCT (Huffman Code Table). When encountering a 0-bit, we move left in the tree, and a 1-bit right in the tree. When the code length increases, this method is too slow to meet speed requirements of Huffman decoding applications.
A more efficient method is based on a time-space trade-off Instead of walking a tree, a LUT (Look-Up-Table) is used. The conventional way of building the LUT can be illustrated by HCT 1 used in MP3 (Table. 1): hcod x, v, hien A lookup table for parallel HCT decoding 1 0, 0, 1 lookup[lxxj = (0, 0, 1) 001 0, 1, 3 lookup[001] = (0, 1, 3) 01 1,0,2 lookup[Olxj=(l,0,2) 000 1, 1, 3 lookup[000] = (1, 1, 3) Table 1. an HCT 1 LUT in MP3 for parallel Huffman decoding, where xx means all permutations of 2 bits.
The LUT contains all indices from 000 to 111. The size of LUT is 2, twice the number of the HCT index. To decode a bit stream using this table three bits (the maximum code length, n) are picked each time. For example if the bit stream is 010000100011, then the index is 010. This matches (1, 0, 2) which means the values, x=1, y=O and hlen=2 were found. Two bits, 01, are discarded from the input. Then another three bits are taken from the string and the process is repeated. For HCT with n-bit maximum code length a LUT would require approximately 2 elements. This method is not suitable for large HCT with a longer maximum code length since the size of the LUT becomes excessive.
To overcome these drawbacks of the two conventional Huffman decoding techniques, it is possible to look carefully at the each HCT, craft efficient LUTs by hand, and use pointers' to different LUTs to handle long length codes. However, the complexity of the decoding process is increased significantly.
Summary of the Invention
This invention proposes a novel transformation of the Huffman code table. It comprises three steps: 1. All codes of the HCT are left-aligned with the most significant bit (MSB) and sorted in ascending order. The rows of the original HCT are then reordered in the same order as the sorted codes.
2. Partition the reordered HCT into some sub-bands; the codes in each sub-band meet the following two rules: (1). all codes in one sub-band have the same code length, nsub; (2). successive codes in one sub-band have successive values.
3. Modify the codes in the reordered HCT to reduce the number of the sub-bands.
Based on the transformed HCT a parallel Huffman decoder can be implemented in software or hardware. A single LUT with minimized size is required to store data symbols of the transformed HCT. The data symbols, stored in the LUT have the same sequence as the codes of the transformed HCT. The number of indices of the LUT equals the number of codes of transformed HCT.
The invented parallel Huffman decoding consists of the following four parts: 1. Create an n-bit (the maximum code length) threshold for each sub-band of the transformed HCT.
2. Store the data symbols of the transformed HCT in a single LUT with a minimized size.
3. Compare n-bit data from the code stream against each threshold, to determine which sub-band the code in the n-bit data belongs to. The LUT index (address) is then calculated based on the rules of the sub-bands.
4. Obtain the value of the data symbol from the index of the LUT, and remove the hien bits from the Huffman code stream.
The invented HCT transformation can be applied to any kind of HCT, no matter whether it is a canonical HCT or a generic HCT. If the invented parallel Huffman decoder is implemented in hardware, the decoding speed can be achieved at a constant rate, of one code per one or more clock cycles.
The Invented Transformation of Huffman Code Table This invented transformation of the HCT includes the following three steps: 1. All codes of the HCT are left-aligned with the most significant bit (MSB) and sorted in ascending order. The rows of the original HCT are then reordered in the same order as the sorted codes.
2. Partition the reordered HCT into some sub-bands; the codes in each sub-band meet the following two rules: (1). all codes in one sub-band have the same code length, nsub; (2). successive codes in one sub-band have successive values.
3. Modify the codes in the reordered HCT to reduce the number of the sub-bands.
The invented transformation can be illustrated on HCT 9 used in MP3 as an example.
The first two columns of Table 2 show the original HCT 9, which are copied from the MP3 standard (ISO 11172-3, Coding of moving pictures and associated audio for digital storage media at up to about 1.SMBIT/s, Part 3 Audio). Each code, heod, in the HCT 9 represents three values, x, y and hien. The itlen is the code length that is varied from 1 -9. The maximum code length, n-bit, is 9 for HCT 9. The x and v are a pair of values which represent two frequency spectra of MP3 audio. The values of x, y and hien are also called data symbol in the HCT. The code and its data symbol occupy one row in the HCT. There are 36 codes used in the HCT 9, 50 there are 36 rows.
HCT 9 HCT-RO 9 _____________ ____________ (Re-ordered FICT 9) x y hien hcod x y hien hcod o o 3 ill 5 5 9 000000000 0 1 3 101 4 5 9 000000001 0 2 5 01001 3 5 8 00000001 0 3 6 001110 5 3 8 00000010 0 4 8 00001111 5 4 9 000000110 0 5 9 000000111 0 5 9 000000111 1 0 3 110 4 4 8 00000100 1 1 3 100 2 5 8 00000101 1 2 4 0101 5 2 8 00000110 1 3 5 00101 1 5 8 00000111 1 4 6 000110 5 1 7 0000100 1 5 8 00000111 3 4 7 0000101 2 0 4 0111 4 3 7 0000110 2 1 4 0110 5 0 8 00001110 2 2 5 01000 0 4 8 00001111 2 3 6 001000 2 4 7 0001000 2 4 7 0001000 4 2 7 0001001 2 5 8 00000101 3 3 7 0001010 3 0 6 001111 4 0 7 0001011 3 1 5 00110 1 4 6 000110 3 2 6 001001 4 1 6 000111 3 3 7 0001010 2 3 6 001000 3 4 7 0000101 3 2 6 001001 3 5 8 00000001 1 3 5 00101 4 0 7 00010!! 3 1 5 00110 4 1 6 000111 0 3 6 001110 4 2 7 0001001 3 0 6 001111 4 3 7 0000110 2 2 5 01000 4 4 8 00000100 0 2 5 01001 4 5 9 000000001 1 2 4 0101 0 8 00001110 2 1 4 0110 1 7 0000100 2 0 4 0111 2 8 00000110 1 1 3 100 3 8 00000010 0 1 3 101 4 9 000000110 1 0 3 110 5 9 000000000 0 0 3 111 Table 2. HCT 9 of MP3 and the reordered HCT-RO 9 of MP3 1. Reorder the rows of the HCT All codes of the HCT are left-aligned with the most significant bit (MSB) and sorted in ascending or descending order. The rows of the original HCT are then reordered in the same order as the sorted codes. The code Ill in the HCT 9 is the largest and the code 000000000 is the smallest. Rows of HCT 9, including x, y, hien and hcod, are reordered as the same order as the ascending order of licod. The reordered HCT 9 is shown in the 3rd and 4th columns of the Table 2 denoted HCT-RO 9 (HCT 9 with Re-Ordering).
2. Partition of HCT-RO into a number of sub-bands Looking at HCT-RO 9 again, two properties are seen: (1). The codes is aligned in ascending order.
(2). All HCT-RO 9 codes, banded with the same code length, have their values in sequence.
Based on two properties, HCT-RO 9 can be divided into a number of sub-bands, without further change to the table. The codes in each sub-band meet the following two rules: (1). all codes in one sub-band have the same code length, nsub (2). successive codes in one sub-band have successive values.
HCT-RO 9 is partitioned into 13 sub-bands which meet the two rules. However, after reordering all HCTs of MP3, a few of the HCT-ROs have many sub-bands, e. g., HCT-RO 24 of MP3 has more than 50 sub-bands. There are 446 sub-bands in all 33 HCTs of MP3. More sub-bands result in a larger and slower program in software, or more logic circuitry in hardware for comparison during the invented parallel Huffman decoding. Therefore it is worth modifying the codes in the HCT-RO to reduce the number of the sub-bands.
3. Modification codes in the HCT 140 This invention proposes two kinds of modification to the codes of HCT-RO without breaking the two rules of the sub-band: a. cutting LSB of longer codes; b. padding x bit(s) at the right side of LSB of shorter codes.
The both ways efficiently reduce the number of sub-bands.
3.a First Modification -Cutting LSB of longer codes in the UCT RO As an example of the cutting modification, Table 3 shows the HCT-RO 9 on the left-hand side, and HCT-ROMC 9 (Huffman Code Table with Re-Ordering and Modification of Cutting) on the right-hand side. The symbol "I" expresses a cutting to the LSB of the codes. After cutting 20 codes the number of the sub-bands of the HCT-ROMC 9 is reduced from 13 to S. HCT-RO 9 IITCT-ROMC 9 LUT With 13 sub-bands ______________ with 5 sub-bands ________ _____________ x y hien licod threshold x y hien hcod Index Note 5 9 000000000 000000000 5 5 9 00000000/0 0 <-offsetl 4 5 9 000000001 Sub-band 1 4 5 9 00000000/1 0 Threshold_i = 3 5 8 00000001 000000010 3 5 8 00000001 1 000000000; 3 8 00000010 Sub-band 2 5 3 8 00000010 2 nsub=8.
4 9 000000110 000000110 5 4 9 00000011/0 3 0 5 9 000000111 Sub-band3 0 5 9 00000011/1 3 4 4 8 00000100 000001000 4 4 8 0000010/0 4 <-offset2 2 5 8 00000101 Sub-band 4 2 5 8 0000010/1 4 2 8 00000110 5 2 8 000001 1/0 5 Threshold_2= 1 5 8 00000111 ____________ 1 5 8 0000011/1 5 000001000; 1 7 0000100 000010000 5 1 7 0000100 6 nsub=7.
3 4 7 0000101 Sub-band 5 3 4 7 0000101 7 4 3 7 0000110 ___________ 4 3 7 0000110 8 0 8 00001110 000011100 5 0 8 0000111/0 9 0 4 8 00001111 Sub-band6 0 4 8 0000111/1 9 2 4 7 0001000 000100000 2 4 7 0001000 10 4 2 7 0001001 Sub-band 7 4 2 7 0001001 11 3 3 7 0001010 3 3 7 0001010 12 4 0 7 0001011 4 0 7 0001011 13 1 4 6 000110 000110000 1 4 6 00011/0 14 <-offset3 4 1 6 000111 Sub-band8 4 1 6 00011/1 14 2 3 6 001000 2 3 6 00100/0 15 Threshold_3= 3 2 6 001001 _____________ 3 2 6 00100/1 15 000110000; 1 3 5 00101 001010000 1 3 5 00101 16 nsub=5.
3 1 5 00110 Sub-band9 3 1 5 00110 17 0 3 6 001110 001110000 0 3 6 00111/0 18 3 0 6 001111 Sub-bandlO 3 0 6 00111/1 18 2 2 5 01000 010000000 2 2 5 0100/0 19 c-offset4 0 2 5 01001 Sub-band 11 0 2 5 0100/1 19 threshold_4= 1 2 4 0101 20 010000000; nsub=4.
1 2 4 0101 010100000 2 1 4 011/0 21 <-offsetS 2 1 4 0110 Sub-band 12 2 0 4 011/1 21 Threshold_5= 2 0 4 0111 ____________ 1 1 3 100 22 011000000; 1 1 3 100 100000000 0 1 3 101 23 nsub=3.
0 1 3 101 Sub-bandl3 1 0 3 110 24 1 0 3 110 0 0 3 111 25 0 0 3 111 _____________ ________ __________ _______ ____________ Table 3.The HCT-RO 9 and HCT-ROMC 9 The cutting codes have longer code length in terms of their position in the HCT-RO.
After cutting, the code length is equal to the length of the codes adjacent to them. It is equivalent to merging a few sub-bands of the HCT RO into one. The cutting codes are also a pair of codes that have most of their bits the same, only the LSB is different, 0 or 1. For example, 00000110 and 00000111 in the HCT-ROMC 9 is a pair of codes.
After cutting the LSB the two codes become one code, 0000011, so that the number of codes in the HCT-ROMC is actually reduced as well, However, each cutting pair of codes represents two sets of data symbols, so a wider space in one index of the LUT is needed to store them. For the codes without cutting in the HCT-ROMC, such wider spaces in the LIlT are wasted. The more pairs of codes that are cut, the less redundant space there is. The modification of cutting is a trade-off between the number of sub-bands and the size of the LIlT.
lb. Second Modification --Padding x bit(s) on the right-hand side of the LSB of some codes in the HCT-RO Padding x bit(s) at the right side of LSB of some codes in the HCT-RO also reduce the number of the sub-bands of the HCT-RO. Table 4 shows the HCT-ROMX 9 (Huffman Code Table with Re-Ordering and Modification of padding X bits). After padding x bit to 9 codes the number of the sub-bands of the HCT-ROMX 9 is reduced from 13 to 6.
HCT-RO 9 HCT-ROMX 9 LUT With 13 sub-bands ___________ with 6 sub-bands _____ ______________ x y hien hcod threshold x y hien hcod Index Note 5 9 000000000 000000000 5 5 9 000000000 0 <-offsetl 4 5 9 000000001 Sub-band 1 4 5 9 000000001 1 threshold_1= 3 5 8 00000001 000000010 3 5 8 00000001x 2,3 00000000; 3 8 00000010 Sub-band 2 5 3 8 00000010x 4,5, nsub=9 4 9 000000110 000000110 5 4 9 000000110 6 0 5 9 000000111 Sub-band3 0 5 9 000000111 7 4 4 8 00000100 000001000 4 4 8 00000100 8 <-offset2 2 5 8 00000101 Sub-band 4 2 5 8 00000101 9 threshold_2= 2 8 00000110 5 2 8 00000110 10 000001000; 1 5 8 00000111 ___________ 1 5 8 00000111 11 nsub=8; 1 7 0000100 000010000 5 1 7 0000lOOx 12,13 3 4 7 0000101 Sub-band 5 3 4 7 0000lOlx 14,15 4 3 7 0000110 ___________ 4 3 7 0000llOx 16,17 0 8 00001110 000011100 5 0 8 00001110 18 0 4 8 00001111 Sub-band6 0 4 8 00001111 19 2 4 7 0001000 000100000 2 4 7 0001000 20 <-offset3 4 2 7 0001001 Sub-band 7 4 2 7 0001001 21 threshold_3= 3 3 7 0001010 3 3 7 0001010 22 000100000; 4 0 7 0001011 ___________ 4 0 7 0001011 23 nsub=7; 1 4 6 000110 000110000 1 4 6 000110 24 <-offset4 4 1 6 000111 Sub-band8 4 1 6 000111 25 threshold_4= 2 3 6 001000 2 3 6 001000 26 000110000; 3 2 6 001001 ____________ 3 2 6 001001 27 nsub=6; 1 3 5 00101 001010000 1 3 5 OOlOlx 28,29 3 1 5 00110 Sub-band9 3 1 5 OOllOx 30,31 0 3 6 001110 001110000 0 3 6 001110 32 3 0 6 001111 Sub-bandlO 3 0 6 001111 33 2 2 5 01000 010000000 2 2 5 Ol000x 34,35 0 2 5 01001 Sub-band 11 0 2 5 OlOOlx 36,37 1 2 4 0101 010100000 1 2 4 0101 38 <-offsetS 2 1 4 0110 Sub-band 12 2 1 4 0110 39 threshold_5= 2 0 4 0111 2 0 4 0111 40 010100000; __________ ____________ _____________ __________ ___________ ______ nsub=4; 1 1 3 100 100000000 1 1 3 100 41 <-offset6 0 1 3 101 Sub-band 13 0 1 3 101 42 threshold_6= 1 0 3 110 1 0 3 110 43 100000000; 0 0 3 111 0 0 3 111 44 usub=3; Table 4.The re-ordered HCT-RO 9, and the modified with padding HCT-ROMX 9 The codes padded with x bits are shown in the table 4. For example the length of 3rd and 4th code in the HCT-RO 9, 00000001 and 00000010, is 8-bit, the length of the Ft, 2nd code, the 5t1 and 6th codes is 9-bit. Therefore the 3 and 4th codes are codes with shorter length in terms of their position in the HCT-RO 9. The code of 00000001 becomes 0000000 lx after padding one x. One x bit represents two values, 0 or 1, so the 0000000lx represents two new codes, 000000010 and 000000011. The new codes have their code length increased and matched with the length of their adjacent codes. Some codes in the HCT-RO may be padded with more x bits, depending on the length of the codes adjacent to them. If two x bits are padded, this expands one code to 4 codes, and so on. The expanded new codes have the same x, y, hien values as their original codes, they are redundant codes in the HCT-ROMX. One bit x padding makes one redundant code, two bits xx padding makes three redundant codes, and so on. The modification of padding is a trade-off between the number of sub-bands and redundant codes.
These two modifications effectively reduce the number of sub-bands and can be flexibly combined to apply to different HCT-RO. Before modification the number of the sub-bands of all HCT-ROs used in MP3 is 446. With the modifications, the number of sub-bands of the all HCT-ROMXs is reduced to less than one third, and the number of the redundant codes is about one third of the total codes. Table 5 (page 9) shows the total number of codes in the original HCTs of MP3, and the number of the codes, sub-bands and the sizes of the LUT for the transformed HCT examples.
The different modifications result in different HCT-ROMs, thus different LIJTs for parallel Huffman decoding. The cutting or padding, or even a combination of the two, gives designers flexibility to choose the best-fit for their design architecture.
n The Invented Parallel Huffman Decoding Based on the transformed HCT the invented parallel Huffman decoder can be implemented in software or hardware. It is designed with the following four parts: 1. Create an n-bit (the maximum code length) threshold for each sub-band of the transformed HCT.
2. Store the data symbols of the transformed HCT into a single LUT.
3. Compare n-bit data from the Huffman code bit stream against each threshold, and determine to which sub-band the code in the n-bit data belongs. Once the sub-band is known, the LUT index is then calculated based on the two rules of the sub-bands.
4. Obtain the value of the data symbol from the index of the LUT, and remove the hien bits from the Huffman code stream.
The parallel Huffman decoding procedures based on the transformed HCT are shown in the Figure 1. The proposed modifications are a trade-off between the number of sub-bands and the size of LUT. It is a trade-off between the size of the decoding program and the ROM (used to store the LUT) in a software implementation of the invented parallel Huffman decoding. Or it is a trade-off between the size of the logic circuitry and the size of ROM in a hardware implementation of the invented parallel Huffman decoding. If the parallel Huffman decoder is implemented in hardware, the decoding speed can be achieved at a constant rate, of one code per one, or more clock cycles.
Details of the four parts of the parallel Huffman decoder are described in the following sections: 1. Create an n-bit threshold for each sub-band of the transformed HCT Each threshold is of n-bit, it is the maximum code length of the HCT. The codes with the least value in the sub-bands are called offset codes in the invention. The threshold of the sub-band is the offset code with zero-padding on its right-hand side to make it of n-bit. For example, the first code in sub-band 3 of the HCT_ROMX is 0001000, the threshold of the sub-band 3 is 000100000. The created thresholds are shown in Tables 3 and 4 for the different transformed HCTs. They are used for comparison with the n-bit data from the Huffman code bit stream in order to determine which sub-band the code in the n-bit data belongs to.
The offset codes can also be the codes with the largest value in sub-bands. The threshold can also be the offset code with one-padding on its right-hand side, to make it of length n-bits.
2. Store data symbols of the transformed HCT into a single LUT One single LUT to store data symbols is needed for the invented parallel HCT-ROM decoding. The data symbols, stored in the LUT have the same sequence as the rows of the transformed HCT. The number of indices of the LUT equals the number of codes of transformed HCT. The positions of the offset codes in the HCT-ROM are fixed, so that the indices of the offset codes in the LUT are known. Different modifications result in the different numbers of codes in the transformed HCT, and therefore different LUTs.
Details of the LUT based on each kind of transformed HCT are given in the following sections, using HCT of MP3 as an example.
2.1 LUT for HCT-RO The size of the LUT for the HCT-RO 9 is calculated as: Number of indices = Ncodes = 36; Data width = Width_x + Widthy + Width_hlen = 4+4+5= 13; Where, 36 is the number of the codes in all of HCT-RO 9. There is no redundant code in the HCT-RO 9. The data width is the width of the LUT. The Width_x is the number of bits for value of the x, the Widtluy is the number of bits for value of the y, the Width_hlen is the number of bits for the code length, hien. The longest code length is 19, 50 the Width_izlen is 5.
2.2 LUT for HCT-ROMX If the padding modification (the second modification) is used, size of the LUT is increased for redundant codes. When one code is padded with one x bit, it actually expands one code to two codes; Reflecting the changes, the number of index of the LUT for the HCT-ROMX is calculated as: Number of indices = Ncodes + Npad_]+3*Npad_2+7*Npad_3+...
Where, Ncodes is the number of codes of the original HCT; Npad_1 is the number of codes with one x bit padding; Npad_2 is the number of codes with two x bits padding, and so on. If the codes are padded with x bit(s), it creates redundant codes. The content of the x, y and hien of the redundant codes are the same as those of the original code, so the content of the original code is repeated in following row(s). If the codes are padded with one x-bit, the content is repeated once; if the codes are padded with two x-bits, the content of the x, y and hien are repeated in three following rows, and so on.
After adding these repeated rows, contents of the LUT are the x, v and hien, they are stored row by row according to the sequence of codes of the HCT-ROM. The equation of the number of indices reflects the redundant codes in the HCT-ROMX.
As example of the LUT of HCT-ROMX 9, there are 36 codes in the original HCT 9, in which 9 codes are padded with one x bit, so it needs 45 indices totally.
Number of indices= 36 + 9=45; Data width = 4+4+5=13; 2.3 LUT for HCT-ROMC When the least bit of the codes is cut it decreases the code length from hien to hien-].
The table 3 shows 10 pairs of codes are cut in the HCT-ROMC. After cutting the pair of the codes is merged into one code, therefore the number of the indices in the HCT-ROMC is reduced to: Number of indices = Ncodes -Npair However, the pair of codes represents two sets of data symbols, the values of x and y. In order to reflect this change, the two sets of x andy values of the pair of codes need to be placed in one row of the LUT, so the width of the LUT is increased to accommodate the second set of x and y. For codes without cutting in the HCT-ROMC, the increased width is redundant space in the LUT. The space can be filled with Os or repeating x and y values of the code.
As an example of HCT-ROMC9, the size of LUT is: Number of indices = 36-10=26 Data width = 2*4 + 2*4 + 5=2 1; Using MP3 as an example the second row of table 5 shows the total number of the codes, the sub-bands and the sizes of the LUT based on the HCT-RO, HCT-ROMX and HCT-ROMC. The number of codes of the HCT-ROMX is increased at about 35%. The sizes of the LUT for the transformed HCT are much smaller than the size of LUT used in the conventional parallel Huffman decoder.
MP3 Total LUT for all HCT-LUT for all HCT-LUT for all HCT-codes ROs ROMXs. ROMCs in* a Number of Size of Number of Size of Number of Size of original sub-bands LUT sub-bands LUT sub-bands LUT ____ HCTs _______ _______ _______ ______ ________ _______ 1410 446 1410w 146 1916w 113 1097w ______ ________ __________ *l3bjt __________ *l3bjt ___________ *2lbjt With further 446 1410w 146 1916w 113 1097w* space saving __________ *8bit __________ *lobit ___________ l8bits Table 5. Size of the LUT required for the parallel Huffman decoding based on the invented transformation of HCTs for MP3 application 2.4 Further space saving on the LUT All codes in one sub-band have the same code length, nsub, thus the value of h/en of each code does not need to be stored in the LUT. For the HCT-RO, nsub equals h/en.
But for the HCT-ROMC, or HCT-ROMX, there is a difference between nsub and h/en, due to the code modification. Instead of storing the full width of h/en, the difference of h/en and nsub, c/h/en, is stored in the LUT, the width of the LUT can be reduced by storing dh/en. The dh/en is 1 for codes with LSB cut, and 0 when the code is unchanged, and -1 when for codes with one x bit padding, and -2 for two x bits padding and so on. If c/h/en is limited to two bits, then the three-bit width of the LUT can be saved by storing c/h/en instead of storing the h/en.
The third row of Table 5 shows the size of the LUT based on this proposed further space saving. The size of a single LUT is minimized by this invented HCT transform, while it is still satisfying for parallel Huffman decoding requirement.
3. Calculate the index of LUT The calculation of the index of the LUT includes two steps: 3.1 comparing the n-bit data with the thresholds of the sub-bands When decoding starts, the Huffman code stream is aligned correctly with the MSB of a code at the beginning of the Huffman code bit-stream. The n-bit data is taken and compared with the set of thresholds of the sub-bands to determine which sub-band the code in the n-bit data belongs to. The comparison details are shown in the Figure 1, it starts from the threshold of sub-band with the shortest code length. Symbols of ">=" (bigger or equal) or ">" or "<=" (less or equal), "<"can be used in the comparison, it depends the sequence of codes in the HCT-ROM. All codes in one sub-band have the same code length, nsub, as stated in rule 1 of the transformed HCT. Once the comparison is true first time, the sub-band is determined and the code length of the sub-band, nsub, is known. The procedure starts to calculate the index of the LUT.
The proposed modifications to the HCT-RO result in fewer sub-bands than the HCT- RO, so there are fewer thresholds. Thus the comparison is executed faster for HCT-ROM than for HCT-RO in software, or in less circuitry in hardware.
3.2 calculating index of the LUT -11-Based on the second rule of the sub-band, "successive codes in one sub-band have successive values", the index of the LIJT can be calculated using the following equation: Index = index_offset + ( value_nsub -value_offset); Where the index_offset is the index of the offset code of the sub-band, the (value_nsub -value_offset) is the difference of the value of nsub bits data and the value of the offset code.
4. Obtain the value of x, y from LUT, shift hlen bits from the Huffman code stream Once the index is calculated, the x, y and hlen or dhlen are read out from the LUT. If the dhlen is stored, then hlen equals sum of the nsub and dhlen. The hlen bits of data that is the decoded Huffman code are shifted out from the bit stream. The paraflel Huffman decoder is ready to decode the next segment. If the LUT of the HCT-ROMC is used, two sets of x and y values of one pair code with LSB cutting are available from the index of the LIJT. The correct set of value of x and y is selected according to the value of the LSB of the code.
n The invented Parallel Huffman Decoder implementation n The invented parallel Huffman decoder in software The following is a loop segment of a parallel Huffman decoding model of HCT-ROMX 9, as an example of parallel Huffman SW decoder. The bit stream contains many Huffman codes in serial. Assume the MSB of a Huffman code is at the first bit of the data stream when the decoding starts. The procedures of the decoding based on the HCT-ROMX are done in each loop for decoding one code. The comparison sequence always starts from the threshold of the sub-bands with the shortest code length, which makes the SW decoder fast.
n=9; If The maximum code length of HCT 9 while ( stream not empty) if (bin2dec(stream( 1: n))>=bin2dec(threshold_6)) //subG threshold; nsub=3; rom_addr = index_offset6 + bin2dec(stream (1: nsub)) -bin2dec(offset6); elseif (bin2dec(stream( 1: n)) >=bin2dec(threshold_5)) I/subS threshold; nsub=4; rom_addr = index_offsetS + bin2dec(stream (1: nsub)) -bin2dec(offsetS); elseif (bin2dec(stream( 1: n))>.=bin2dec(threshold_4)) II sub4 threshold; nsub=6; rom_addr = index_offset4 + bin2dec(stream (1: nsub)) -bin2dec(offset4); elseif (bin2dec(stream( 1: n))>.=bin2dec(threshold_3)) II sub3 threshold; nsub=7; rom_addr = index_offset3 + bin2dec(stream (1: nsub)) -bin2dec(offset3); elseif (bin2dec(stream( 1: n))>=bin2dec(threshold_2)) II sub2 threshold; nsub=8; rom_addr = index_offset2 + bin2dec(stream (1: nsub)) -bin2dec(offset2); else II subi threshold; nsub=9; rom_addr = index_offset l+bin2dec(stream(l: nsub)) -bin2dec(offset 1); end x=lut9(rom_addr, 1); II read out x y=lut9(rom_addr,2); 1/ read out y dhlen= lut9(rom_addr,3); II read out dhlen hien = nsub+dhlen; II calculate Hlen stream = stream(hlen+l:end); II shift hien bit out from the bit stream end Where, the thresholds, the offset codes and their indices are shown in the Table 4. The bin2dec is a function which transfers binary bits to a decimal value. The lut9 is the LUT of the HCT-ROM 9, the x and y values of the codes are stored in the lut9(index, 1) and lut9(itzdex,2). The dhlen is stored in the lut9(index, 3).
n The invented parallel Huffman decoder in hardware The invented parallel Huffman decoding based on the HCT-ROM can be implemented in hardware with maximum throughput at one code per clock cycle. The hardware diagram of the HCT-ROM decoder is shown in Figure 2. It comprises: -At least one stream buffer with a synchronous clock, which shifts the stream data under control of the hien at an edge of clock.
-At least one synchronous ROM used as the LUT, which stores the values of the x, y, dhlen of the HCT-ROM.
-At least one ROM address generator built by logic circuitries, which takes the codebook index and n-bit of the stream data as inputs, and outputs the address of ROM.
The stream data is loaded into the stream buffer, the hien bits are shifted after each code is decoded. The stream buffer is responsible for aligning the stream so that decoding starts at a correct code boundary. The n-bit data is taken for the parallel decoding. The block of rom_addr generator consists of logic circuitries which compares the n-bit data with the thresholds and calculate the address of the ROM. The rom_addr is updated once the codebook index or the value of stream[ 1:n] is updated. The dc is a clock to the stream buffer and the LUT, they are synchronous circuitry. At rising edge of the dc, x, y and dhlen are updated for the current code. The hien is a feedback to the stream buffer to move hien bits from the buffer for next code decoding.
The decoding throughput of the hardware implementation of this invention is at a constant rate, or one code per cycle at maximum rate, for any type of Huffman code book, and any length of code word..

Claims (7)

  1. -13 -Claims: 1. Transformation of HCT for realizing a parallel Huffman decoder with minimized size of LUT, in which all codes of the HCT are left-aligned with the most significant bit (MSB) and sorted ii ascending or descending order, the rows of the original HCT are then reordered ui the same order as the sorted codes.
  2. 2. The reordered HCT as in 1, where the HCT-RO is partitioned into a number of sub-bands, the codes in each sub-band meet the following two rules: (1). all codes in one sub-band have the same code length, nsub (2). successive codes in one sub-band have successive values.
  3. 3. The reordered HCT as in 1, where the codes of the HCT-RO are modified in two ways in order to reduce the number of the sub-bands: a. cuttthg LSB of longer codes; b. padding x bit(s) at the right side of LSB of shorter codes.
  4. 4. The reordered HCT as in 1 or further modified HCT-ROM as in 3, where an n-bit (the maximum code length) threshold for each sub-band is created. The threshold of the sub-band is the offset code with zero-padding on its right-hand side to make it of n-bit.
  5. 5. The reordered HCT as in 1 or further modified HCT-ROM as in 3, where the data symbols store as the same sequence as the codes in the transformed HCT into a single LUT. The number of indices of the LUT equals the number of the codes of the transformed HCT. The width of the LUT equals a sum of width of the data symbol and dhlen.
  6. 6. Means for implementing the parallel Huffrnan decoder based on the transformed HCT includes four parts: (1) Create an n-bit (the maximum code length) threshold for each sub-band of the transformed HCT.(2) Store the data symbols of the transformed HCT into a single LUT. dhlen is stored in the LUT instead of hien to further save the width of the LUT.(3) Compare n-bit data from the Huffman code stream against each threshold, and to judge which sub-band the code in the n-bit data belongs to. Once the sub-band is known, the nsub and index of the offset code are known. The index of the nsub data is calculated as the sum of the index of the offset code and difference of the values of the nsub data and the offset code.(4) Obtain the data symbol from the index of the LUT, and shift the hien bits from the Huffman code stream.
  7. 7. The invented Huffman decoder hardware structure (HW) comprises: -At least one stream data buffer with a synchronous clock, which shifts the in-stream data under control of the hien at an edge of clock.-At least one ROM for LUT with a synchronous clock, which stores the contents of the x, y and dhlen of codes in HCT-ROX. The output of the LUT is updated at an edge of clock.At least one ROM address generator built by logic circuitry, which takes the codebook index and n bits of stream data as inputs, and generates the ROM address.
GB1101178.0A 2010-08-28 2011-01-24 Huffman decoder using modified Huffman Code Table Withdrawn GB2483319A (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GBGB1014347.7A GB201014347D0 (en) 2010-08-28 2010-08-28 Huffman code table transform and parrallel Huffman decoding

Publications (2)

Publication Number Publication Date
GB201101178D0 GB201101178D0 (en) 2011-03-09
GB2483319A true GB2483319A (en) 2012-03-07

Family

ID=43013374

Family Applications (2)

Application Number Title Priority Date Filing Date
GBGB1014347.7A Ceased GB201014347D0 (en) 2010-08-28 2010-08-28 Huffman code table transform and parrallel Huffman decoding
GB1101178.0A Withdrawn GB2483319A (en) 2010-08-28 2011-01-24 Huffman decoder using modified Huffman Code Table

Family Applications Before (1)

Application Number Title Priority Date Filing Date
GBGB1014347.7A Ceased GB201014347D0 (en) 2010-08-28 2010-08-28 Huffman code table transform and parrallel Huffman decoding

Country Status (1)

Country Link
GB (2) GB201014347D0 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2637407A1 (en) * 2012-03-05 2013-09-11 Samsung Electronics Co., Ltd Apparatus and method for decoding Huffman codes
WO2018106975A1 (en) * 2016-12-11 2018-06-14 Microsoft Technology Licensing, Llc Multi-symbol, multi-format, parallel symbol decoder for hardware decompression engines

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002057585A (en) * 2000-08-07 2002-02-22 Victor Co Of Japan Ltd Decoder
US6373412B1 (en) * 2000-12-15 2002-04-16 International Business Machines Corporation Fast JPEG huffman encoding and decoding
US20100315269A1 (en) * 2009-06-12 2010-12-16 Industrial Technology Research Institute Decoding Method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002057585A (en) * 2000-08-07 2002-02-22 Victor Co Of Japan Ltd Decoder
US6373412B1 (en) * 2000-12-15 2002-04-16 International Business Machines Corporation Fast JPEG huffman encoding and decoding
US20100315269A1 (en) * 2009-06-12 2010-12-16 Industrial Technology Research Institute Decoding Method

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2637407A1 (en) * 2012-03-05 2013-09-11 Samsung Electronics Co., Ltd Apparatus and method for decoding Huffman codes
US8674857B2 (en) 2012-03-05 2014-03-18 Samsung Electronics Co., Ltd. Apparatus and method for decoding
WO2018106975A1 (en) * 2016-12-11 2018-06-14 Microsoft Technology Licensing, Llc Multi-symbol, multi-format, parallel symbol decoder for hardware decompression engines

Also Published As

Publication number Publication date
GB201014347D0 (en) 2010-10-13
GB201101178D0 (en) 2011-03-09

Similar Documents

Publication Publication Date Title
KR100894002B1 (en) Device and data method for selective compression and decompression and data format for compressed data
JP3136796B2 (en) Variable length code decoder
US7777654B2 (en) System and method for context-based adaptive binary arithematic encoding and decoding
US7538696B2 (en) System and method for Huffman decoding within a compression engine
JP3224164B2 (en) decoder
US5973626A (en) Byte-based prefix encoding
KR100717055B1 (en) Method of decoding bin values using pipeline architecture, and decoding apparatus therefor
US5818368A (en) Method and apparatus for lossless digital data compression
GB2538218A (en) System and method for compressing data using asymmetric numeral systems with probability distributions
US8810439B1 (en) Encoder, decoder and method
KR20170036683A (en) Encoder, decoder and method
KR0178201B1 (en) Variable length decoding apparatus
JP4098187B2 (en) Variable length code decoding apparatus and method
Nikara et al. Multiple-symbol parallel decoding for variable length codes
GB2483319A (en) Huffman decoder using modified Huffman Code Table
US5648775A (en) High speed variable length code decoding apparatus
JP2001069013A (en) Method for padding variable length code bit to fixed position
JP3853439B2 (en) High speed variable length code decoding apparatus and high speed variable length code decoding method
US7683809B2 (en) Advanced lossless bit coding
JPH08223055A (en) Variable-length cord decoder
JP3429623B2 (en) High-speed variable-length code decoding device
Kumar et al. Bit stream compression used for FPGA using Golomb coding
KR100207428B1 (en) Variable length coding apparatus and method adaptive to changes of the hoffman codes
KR100686354B1 (en) Huffman decoding method and device for using variable length tree
JP2934603B2 (en) Method and apparatus for decoding variable length code

Legal Events

Date Code Title Description
WAP Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1)