CN1613188A - 霍夫曼编码 - Google Patents
霍夫曼编码 Download PDFInfo
- Publication number
- CN1613188A CN1613188A CNA028198115A CN02819811A CN1613188A CN 1613188 A CN1613188 A CN 1613188A CN A028198115 A CNA028198115 A CN A028198115A CN 02819811 A CN02819811 A CN 02819811A CN 1613188 A CN1613188 A CN 1613188A
- Authority
- CN
- China
- Prior art keywords
- value
- code word
- decoding
- subclauses
- clauses
- 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.)
- Granted
Links
Images
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/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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
Abstract
通过识别高阶1或0的连续位串(216)和后续高阶1或0的连续位串，根据其行程计数和位值，取回每个位串的表条目(222)，直到取回的条目包含解码输出符号为止，或者直到代码字的剩余位的数目在预定阈值内为止，实现对霍夫曼代码的解码。剩余二进制位被用作查寻表中的偏移量，但是通过消除前导1和0，已减小了查寻表的大小。连续位串最好由硬件加速器处理，以便识别重复的二进制位，计算位串中的二进制位，并将该信息返回给主处理器。实现了对标准代码解码的高效性；不过也可解码非标准代码。
Description
技术领域
本发明涉及数据压缩，具体地说，涉及对霍夫曼编码代码字的解码。
背景技术
霍夫曼代码广泛用在数据压缩和通信领域中。一些应用包括JPEG图像压缩和MPEG视频与音频压缩。霍夫曼代码是字长度可变的代码，这意味着用于组成消息的单个符号分别由不同长度的不同位序列表示9编码)。代码字的这种特性有助于降低消息数据中的冗余量，即，它使数据压缩成为可能。例如，可用下述代码字表示符号A、B、C和D：
表1霍夫曼代码表的一个例子
| 符号 | 代码字 |
| A | 0 |
| B | 10 |
| C | 110 |
| D | 111 |
所有代码字是唯一可解码的；例如，位序列“01101110100”解码成‘ACDABA’。该组代码字被称为符号列表或字母表。唯一性是从霍夫曼代码的“前缀性质”得到的；即，得自于如果代码字的任意最左侧的或“前端”子串和霍夫曼解码表中的代码字相符，则不必检查前端子串之外的任意其它位的事实。例如，代码字“10”被分配给符号“B”。从而其它任何代码字都不从“10”开始。
霍夫曼的使用能获得压缩，因为不同的符号具有不同的出现概率。通过根据符号各自的出现概率，剪裁对应于这些符号的代码长度，使用该性质是有益的。用较短的代码字对出现概率较高的符号编码，而用较长的代码字对出现概率较低的符号编码。较长的代码字仍然会出现，但是由于它们的出现概率较小，因此由于霍夫曼编码的缘故，典型位串中所有代码字的总代码长度会较小。
建立霍夫曼代码的算法以“编码树”为基础。通常已知的算法步骤是：
1.按照概率的降序，排列符号。
2.将概率最小的两个符号联合成一个新符号，所述新符号的概率为这两个符号的概率之和。
3.重复步骤2，直到只剩下概率为1的一个符号为止。
4.从根部(产生的概率为1的符号)到原始符号，沿着编码树行走，并向每个下层分支赋值1，向每个上层分支赋值0，或者反之亦然。
例如，表2中列举了一些字母的概率，图1中表示了通过对这些概率应用上述算法建立的可能的霍夫曼树之一。
表2字母表的子集中的概率分布的例子
| E | 2/25 |
| X | 1/25 |
| A | 2/25 |
| M | 2/25 |
| P | 1/25 |
| L | 1/25 |
| O | 2/25 |
| F | 2/25 |
| H | 1/25 |
| U | 1/25 |
| C | 1/25 |
| D | 1/25 |
| I | 1/25 |
| N | 2/25 |
| G | 1/25 |
| 空格 | 3/25 |
代码字中的每个“0”位对应于经过树中的“0”分支，图1中，这是通过向上走来实现的；向下走经过“1”分支。通过在右侧从根部开始，并逐一经过对应于代码字的每一位的分支，在霍夫曼树上表示代码字“11000”。头两位“11”对应于两个1分支，或者两个向下的台阶。下一位“0”对应于上移，即沿着0分支，如箭头所示。经过剩余位“00”的另外两个0分支，通向整个代码字“11000”的输出符号，这里所述输出符号是位于图1左侧的字母“P”。
从而从图1可看出，字母“P”的代码为“11000”，并且对于任意指定的概率分布，存在数种可能的霍夫曼表。
解码霍夫曼代码的根本问题在于解码器事先不能知道输入代码字的长度是多少。
通过提供大量专用存储器，能够极快地检测霍夫曼代码。对于一组其最大字长度为N位的霍夫曼代码字来说，需要2N个存储单元，因为N个输入位被用作查寻表中查找对应代码字的地址。例如表1的解码符号需要23＝8个存储单元。始于“0”的所有地址被用于保存符号“A”，始于“10”的所有地址保存符号“B”等等。当代码字被应用于查寻表时，立即进行该片断的解码。随后，输入的位流被移动刚被解码的代码字的位长度，使下一代码字进入可操作的解码位置。对于具有最大长度为19位的代码来说，存储器需求大大增大。
需要较少存储器的一种技术是逐位解码，该技术如下进行解码。获取一位，并与字长为1的所有可能代码比较。如果未发现匹配，则移入另一位，试图从字长为2的所有代码字中找出位对。继续上述过程，直到找到匹配为止。虽然这种方法存储器效率很高，但是这种方法很慢，尤其是如果被解码代码较长时更是如此。
另一种解决方案使用内容可寻址存储器(CAM)。位片(即长到足以容纳任意代码字，于是长度和最大代码字相同的位串)被提供给包含作为“地址”的所有代码字和作为“内容”的存储器指针的CAM的输入端。CAM包含引用RAM表中的符号和相关代码字长度的存储器指针。一旦代码字被解码，则输入的位流随后被移动解码代码字的长度，并重新开始解码。高效实现的CAM方案快速，但是仍然需要用于指针的额外存储器。此外，不易于在所有技术中实现CAM。在美国专利No.5208593(下面进一步说明)中描述了基于CAM的方法。
如同在上面的例子中所示，使用可变代码字长度方面的问题在于速度和合理的存储器使用之间的均衡。
标准霍夫曼代码特别引人注意，因为它们使解码变得容易。PKzip(文件压缩/解压缩应用程序)，MPEG-1层3(MP3)和JPEG默认基线编码器都使用标准霍夫曼表。在多媒体和通信的其它领域也有应用。
标准霍夫曼代码的特征在于和长度为(n-1)的最大霍夫曼代码相比，长度为n的最小霍夫曼代码的最高有效(n-1)位的值较大，只要霍夫曼表是几乎所有代码都具有一个前导1位的那种霍夫曼表。对于主要由其前导位为1的代码组成的霍夫曼表来说，即通过反转所有代码字位得到的表，适用相反的规则：和长度为(n-1)的最小霍夫曼代码相比，长度为n的最大霍夫曼代码的值较小。将霍夫曼表转换成标准格式不会降低编码效率，因为从表3中的下述例子可看出，转换不会改变单位代码字的二进制位的数目。
表3常态代码字对标准代码字
| 树代码 | 代码2 | 代码3 | 标准 | |
| A | 001 | 111 | 100 | 010 |
| B | 0000 | 1101 | 0011 | 0000 |
| C | 1001 | 0010 | 1011 | 0001 |
| D | 101 | 000 | 000 | 011 |
| E | 01 | 01 | 11 | 10 |
| F | 0001 | 1100 | 1010 | 0010 |
| G | 1000 | 0011 | 0010 | 0011 |
| H | 11 | 10 | 01 | 11 |
根据关于标准代码的上述逆规则，长度为3的代码字(例如010和011)总是大于长度为4的代码(例如0000，0001，0010，0011)的起始3位。另外，代码长度保持不变。
另外值得注意的是由于上述特征的缘故，标准代码通常从一串1(或0)开始。在美国专利No.5208593(“Tong”)中，在JPEG编码的环境下使用了从一串1开始的性质，因为JPEG霍夫曼表由从1的位串开始的数个代码组成。该参考文献将“前导1检测”应用于在JPEG中使用的霍夫曼代码。关于下一代码字的从最高有效位(MSB)(下面，“前导位”将意味着最高有效位或最左侧的位)的一连串“1”的长度，检测要解码的下一代码字。在已知该长度或计数之后，根据给定的最大代码字长度，也知道了该代码字中，剩余二进制位的最大数目。一连串的1(和之后的0，因为它总是已知)被屏蔽掉。剩余的二进制位，加入连续的(前导)1的数目被用于形成包含符号的RAM表中的地址。
Tong的方法只对具有为1的前导位串的霍夫曼代码字有效。Mp3音频标准利用具有为0的前导位串的代码字规定霍夫曼表。此外，Tong的方法只对标准霍夫曼表起作用，并且使用许多存储器。如果将Tong的方法应用于下表4中所示的霍夫曼表(Hashemian，R.MemoryEfficient and High-Speed Search Huffman Coding，IEEE Transactionson Communications，Vol.43 No.10，(1995))，则Tong的方法不是很好，因为该霍夫曼表是单侧增长表(single-side growing table)，即构建成使“子树”较小的表。但是，Tong的方法将13个字用于包含36项的第二表中的地址，总共需要13+36＝49个字。如果应用于在消除前导1之后，最大代码字长度为8位的JPEG标准AC表，则Tong的方法的存储器效率将较低，因为对于剩余的这8位，Tong的方法要使用查寻表中的28个存储单元。
Potu的美国专利No.6219457公开一种霍夫曼解码预处理，该解码预处理分别根据输入的代码流是按照MPEG标准(用前导0编码)编码，还是按照JPEG或数字视频标准(用前导1编码)编码，计算代码字的连续前导0的数目，或者计数代码字的前导1的数目。计数被用于索引编入第一查寻表中，以确定可变长度代码(VLC)解码表的基本地址。代码字中在计数位之后的预定数目的二进制位和基础地址组合，以选择正确的VLC解码表，从该正确的VLC解码表取回输出符号。
但是，根据Potu的方法适用的应用，Potu的方法只对前导1位串或者只对前导0位串起作用；此外，Potu的方法对同一代码字内连续的位串无效。和Tong方法的情况一样，只有当霍夫曼代码是标准霍夫曼代码时，Potu方法才能够处理霍夫曼代码，并且Potu的方法不能对同一代码字中连续的位串解码会导致解码表较大。
表4摘自Hashemian的著作的霍夫曼表
| CL | 符号 | 霍夫曼代码 |
| 22 | 0001 | 0001 |
| 444444 | 020304050607 | 100010011010101111001101 |
| 5 | 08 | 1110 0 |
| 666 | 090a0b | 1110 101110 111111 00 |
| 77 | 0c0d | 1111 0101111 011 |
| 88888 | 0e0f101112 | 1111 10001111 10011111 10101111 10111111 1100 |
| 999 | 131415 | 1111 1101 01111 1101 11111 1110 0 |
| 1010101010 | 161718191a | 1111 1110 101111 1110 111111 1111 001111 1111 011111 1111 10 |
| 121212 | 1b1c1d | 1111 1111 11001111 1111 11011111 1111 1110 |
| 1313 | 1e1f | 1111 1111 1111 01111 1111 1111 1 |
Hashemian的解码方案以“群聚”输入位为基础，如上所示。前L位被“群聚”，以便用作表中的指针。如果代码长度为L位或更少，则当前表包含该符号，该代码被立即解码。如果代码较长，则表具有相对于其它表的指针，所述其它表包含从这些特定L位开始的代码字。这些新表同样由下一L位群集寻址，直到最终找到符号为止。减小L能够提高存储器效率，但是解码步数增大。
例如，对于L＝4来说，为了查找一个符号的位置，13-位字需要四步(13/4＝3.25)。在第一查寻表中，所述13位的头4位识别相对于第二查寻表的指针，第二查寻表的代码都开始于这4位。从而不再需要这4位。于是，对于第二查寻表来说，剩余9位；在第二查寻表之后，对于第三查寻表来说，剩余5位；在第三查寻表之后，剩余1位，这需要第四步骤。即，这三个查寻表构成解码中的前三步，剩余一位的处理构成第四解码步骤。JPEG使用13位的最大长度，而Mp3中的最长代码字为19位。
Hashemian的方案存在几个缺点。它依赖于位屏蔽和比较步骤。另外，由于该方法没有利用标准代码的性质，该算法不能简单地跳过连续的1或0，而是以每次最多L位的速率处理代码；于是，长代码需要较长的解码时间。此外，使用上面的单侧增长表和为4的群集长度的Hashemian解决方案占用122字的存储空间。
于是，需要一种快速并且存储器效率高的解码方法，该解码方法足够灵活，足以处理霍夫曼代码，而与其是否是标准霍夫曼代码无关，同时该解码方法又足够稳健，能够利用可从呈标准形式的解码代码获得的效率。
加剧该问题的另一事实是一般的CPU未被很好地配备，不能处理可变长度的代码字，而是对诸如16位或32位之类自然长度起作用。利用任意掩码的位字段的移位和屏蔽以及基于结果的搜索较慢。另外，霍夫曼解码算法需要频繁比较和基于比较结果的分支，对于具有深(deep)流水线的CPU来说，这是非常低效的。一些数字信号处理器(DSP)能够胜任位字段处理，但是不幸的是也具有长的流水线。应避免大型的if/then或swithc/case-结构。
纯软件解码较慢。例如查找流中的第一个“1”需要利用2的指数的数个比较操作，或者其它复杂任务。就硬件来说，查找前导1中一项简单的任务，只需要组合逻辑，而对于常规的CPU指令来说，需要数个移位/屏幕/比较操作。
进行霍夫曼解码需要使用专用的独立硬件组件，例如移位器和加法器等。在诸如高清晰电视(HDTV)解码器之类专用装置中，这种方法是可行的，但是对于具有高性能处理器的系统来说，这是资源的浪费，因为这些组件已存在于主机中。
加速器可被实现成完全独立的解码器(松散耦接)，它可以自己访问存储器，并输入数据，从而主CPU能够执行它自己的任务。虽然必须重复数种资源(加法器、存储器接口单元、移位器等)，但是性能较高。不幸的是，霍夫曼解码需要相当大的表格，如果被保存在解码器的内部存储器中，则所述表格要求存储器相应较大，成本较高。如果表格保存在公共存储器中，则解码器可能阻塞存储器总线，因为解码是非常依赖于存储器的应用。
发明内容
一方面，本发明涉及一种对一系列霍夫曼编码代码字中的当前代码解码的方法、设备和程序。检测代码字中某一位的值。计算该位及后续的值相同的连续二进制位的当前计数值。根据当前计数值，从解码表取回一个条目。每次对这些已计数二进制位之后的二进制位反复进行检测和计算，直到最后取回的条目指出不需要再进行重复为止。
在本发明的另一方面，如果最后取回的条目不包含构成当前代码字的解码的输出符号，则这些计数二进制位之后的至少一位被用于取回包含构成当前代码字的解码的输出符号的条目。
另一方面，本发明涉及确定串的前导位的值，以及包括该位的行程的计数。值检测器检测该值，如果检测到的值等于预定的二进制位值，则第一反相器反转将位串中值不同于预定二进制位值，并且有效性低于具有预定二进制位值的最高有效位的各位转换成预定二进制位值。第二反相器反转来自数字扩展器的位输出。倒转器倒转第二反相器反转的二进制位的顺序，从而产生倒转串。thermometer代码评估器计算倒转串中具有预定值的二进制位的行程计数。
另一方面，本发明涉及一种计算机可用介质，所述计算机可用介质具有对霍夫曼代码解码的计算机可读程序代码单元。所述单元包括霍夫曼解码表，所述霍夫曼解码表以条目的形式，具有从连续排列的霍夫曼编码代码字中，识别代表解码表中的尾部偏移量的剩余二进制位的偏移量。根据连续排列的各个连续的取值相同的二进制位的多个计数，预先确定代表尾部偏移量的剩余二进制位的数目。取值相同的二进制位的有效性高于剩余二进制位的有效性，并且通常并不都具有相同的二进制值count-to-count。
结合附图，根据下述详细说明，本发明的其它目的和特征将变得显而易见。但是，附图只是用于举例说明，而不是对本发明的限定，本发明的范围由附加权利要求限定。
附图说明
图1表示了霍夫曼树；
图2是根据本发明的例证解码系统；
图3是根据本发明，对霍夫曼编码代码解码的过程的流程图；
图4表示了根据本发明的图2中的解码系统的一个组件。
具体实施方式
本发明提供一种快速并且存储器效率高的霍夫曼代码流解码方法。解码以代码字的开头部分中的位串，即“0000...”和“1111...”串的检测为基础。在找到第一个n位长度的连续1或0之后，再次对代码字中的剩余位(从n+1位置向前)搜索连续的1或0，直到能够确定代码字中只剩下几位为止，此时，它们可用于从存储表中查寻对应的符号。这种过程可被看作在霍夫曼树中行进最大长度的“直线行程”，并且每次检测到通向新“子树”的转折点时停止。有利的是，每次最少2位处理代码字(前导0或1和指示“转折点”的后续位)。
例如，在图1中，一般如下进行关于字母“P→11000”的解码过程：首先，检测离开全1/0路径的偏离，意味着已到达树中一个不同的分支。之后，除去不再需要的前2+1位(“110”)，“00XXXXX...”仍须被解码。这里，X是属于下一代码字的位。省略号不太具体，下面指的是接下来的位，而无论这些后续位是否属于后续一个代码字。参见图1，处理后的(“110”)串意味着必须下行两个“1”分支和上行一个“0”分支。
剩余的位“00XXXXX”再次被送入前导1/0检测器。这种情况下，检测器检测到我们正沿着“0000...”方向行进。参见图1，由于全零方向上，最大剩余代码长度为2(事实上在任意方向上，最大剩余代码长度为2)，我们已到达路线“11000”的终点，现在“11000”已被解码。
相反，当面对剩余的位“00XXXXX”时，美国专利No.5208593(Tong)已检测了连续的高位1，没有检测高位0的任何手段。Tong改为将高达“最大剩余长度”的剩余高价位用作解码表中的查寻关键字。最大剩余长度会远远大于2，于是和根据本发明所需的表相比，需要更大的表。
另外，由于本发明的方法以每次最少两位(从前导位到值不同的一位)处理代码字，因此即使是非标准霍夫曼编码代码字，本发明也能够快速解码，非标准霍夫曼编码代码字的特征在于不具有一样多的取值相同的前导位串，在不求助于较大存储器的情况下，Tong的方法不能处理非标准霍夫曼编码代码字。
和Potu相反，本发明不依赖于第二表查寻；相反，在第一次查寻获得许多输出符号。另外，和Tong的方法相同，Potu的方法需要比本发明更大的表，因为只预处理单位行程计数(single bit run count)，并且类似于Tong的方法，为了处理非标准霍夫曼代码，需要更大的表。
如图2中所示的例证解码系统200包括发送霍夫曼编码代码字204，以便由接收缓冲器206顺序接收的编码位流源202。主处理器或控制部件208(可以是微处理器)接收缓冲器206的输出，并将缓冲器控制指令发送给缓冲器206。主处理器208将该输出中的一组位发送给前导0/1计数计算器216(它可以是硬件加速器)。计算器216将该组中取值相同的连续二进制位的计数返回给主处理器208。主处理器208根据该计算确定地址，并调用存储器读取机制220读取驻留在RAM 224或其它存储器，例如ROM中的解码表222中的地址。根据从该地址读取的数据，主处理器208确定(1)是否需要关于另一组的另一计算，(2)是否需要在已计数二进制位之后的二进制位，或者(3)读取的数据是否包括和当前代码字对应的输出符号，从而当前代码字已被解码，即构成当前代码字的解码的输出符号。在第一种情况下，主处理器208调用前导0和1计数计算器216进行另一次迭代。在第三种情况下，当前代码字被输出给解码数据接收器226，解码数据接收器226可以是反向离散余弦变换处理器用接收缓冲器。在需要已被计数的二进制位之后的二进制位的第二种情况下，主处理器208选择预定数目的这些二进制位，作为其值用作自表222中的当前位置的“尾部偏移量”的串，以便解码当前字。这里该偏移量被称为“尾部偏移量”，因为提供该偏移量的选择位(下面称为“尾部偏移位”)位于要解码的代码字的结尾。
图3是提供根据本发明如何实现解码的更多细节的例证流程图。出于举例说明的目的，假定接收缓冲器206包含位串“00011111010”。
该过程从当前一组位和当前代码字开始。在处理中的任意时刻，在其最低有效末端，所述当前组可扩展足够远，从而包括当前代码字，或者情况可能是当前代码字比当前组长。在本例中，组的长度被设置成8位，因为已用8位的搜索字段长度配置0/1计数计算器216。于是本例中的当前组为“00011111”，并且被传送给计算器216。计算器216检测前导位的值为“0”(步骤S302)，并将前导位“0”的连续位重复的计数计算为当前计数值，即，当前计数值从前导位开始，并包括后续的，数值相同的连续位。计算器216将为3的当前计数值返回给主处理器208(步骤S304)。
主处理器208使用当前计数值3作为解码表222中的偏移量，指向表222的地址。处理器208将该地址提供给存储器读取机制220。机制220取回该地址的条目，并将该条目提供给处理器208(步骤S306)。根据该条目的内容，处理器208确定解码当前代码字，是否需要再一次计数连续位(步骤S308)。如果是，则如同本例中那样，使下一组成为当前组(步骤S310)，并进行另一次重复(步骤S302～S306)。在本例中，成为当前组的下一组是“1111010X”，这里X代表紧接着进入接收缓冲器206的位，于是被处理器208取回。注意就确定当前组为“1111010X”来说，跳过在前位串“0001”。这四位不再需要，因为高价0已被计数，根据“1”位是终止一串零的唯一一位的事实，已知该“1”位。
在下一次重复中，在检测了前导位(步骤S302)和计算了当前计数值(步骤S304)之后，处理器208从解码表222取回另一条目(步骤S306)，或者转向并调换另一解码表以便替换表222。根据新取回的条目，处理器208确定是否需要另一次重复(步骤S308)，以及(步骤306)最后取回的条目是否不包含构成当前代码字的解码的输出符号(步骤S312)。本例中，这是解码同一当前代码字的过程中的第二次重复。由于当前代码字一直未被解码(步骤S312)，则解码当前代码字需要尾部偏移位。从(步骤S306)最后取回的条目，处理器208知道尾部偏移量由两位提供，并取回下两位(步骤S314)，在本例中，所述下两位可被看作“10”。下面将尾部偏移位的最大位长称为“尾部阈值”，本例中尾部阈值为2。处理器208使用尾部偏移量向后指向其在当前解码表中的当前位置，向前指向输出符号驻留的位置，随后取出输出符号(步骤S314)。由于不再需要刚被用于取回输出符号的二进制位，在准备下一代码字中，处理器208向后指向这些二进制位(步骤S316)。
随后确定是否已完成来自源202的位流的解码(步骤S318)。如果从接收缓冲器206接收的所有位都已被解码，则处理停止，并等待当在接收缓冲器206中收到另外的二进制时重新开始。另一方面，如果不是全部二进制位都已被解码，则处理循环回起点，以便进行另一次重复，其中使下一组成为当前组(步骤S310)。另一方面，可利用位流中的特殊代码字指示来自源202的位流的解码的完成。在这种实现中，步骤S316包括比较特殊代码字和刚被解码的二进制位之后的二进制位。如果它们相符，则完成处理，并依据解码将重新开始的信号再继续处理。另一方面，如果它们不相符，则处理返回步骤S310。
从而，在本例中，在解码代码字的过程中，计数0位的行程，跳过一位，并计数1位的行程。代码字的最后两位提供解码表中的尾部偏移量。尾部偏移位的数目被限制为最大为2位，该最大值确定最终重复之前的重复次数，本例中，所述重复次数为2次。
下表5用在根据本发明的另一解码例子中，并使用以如上表4标记的霍夫曼表为基础，按照下面讨论的格式化建立的例证查寻表。
表5例证的查寻表
| 行# | 条目标识符 | 符号/偏移地址 | 移位量/代码长度 | ||
| -13 | S | 0x1f | 13 | ||
| -12 | S | 0x1e | 13 | ||
| -11 | S | 0x1d | 12 | ||
| -10 | B | +31 | 15 | ||
| -9 | S | 0x1a | 10 | ||
| -8 | B | +29 | 14 | ||
| -7 | B | +25 | 14 | ||
| -6 | B | +21 | 14 | ||
| -5 | B | +17 | 14 | ||
| -4 | B | +13 | 14 | ||
| -3 | B | +9 | 14 | ||
| -2 | B | +5 | 15 | ||
| -1 | B | +3 | 14 | ||
| 0 | 2 | 13 | |||
| 1 | S | 0x01 | 2 | ||
| 2 | S | 0x00 | 2 | ||
| 3 | 0x02 | 4 | |||
| 4 | 0x03 | 4 | |||
| 5 | 0x04 | 4 | |||
| 6 | 0x05 | 4 | |||
| 7 | 0x06 | 4 | |||
| 8 | 0x07 | 4 | |||
| 9 | 0x08 | 5 | |||
| 10 | 0x09 | 5 | |||
| 11 | 0x09 | 6 | |||
| 12 | 0x0a | 6 | |||
| 13 | 0x0b | 6 | |||
| 14 | 0x0b | 6 | |||
| 15 | 0x0c | 7 | |||
| 16 | 0x0d | 7 | |||
| 17 | 0x0e | 8 | |||
| 18 | 0x0f | 8 | |||
| 19 | 0x10 | 8 | |||
| 20 | 0x11 | 8 | |||
| 21 | 0x12 | 8 | |||
| 22 | 0x12 | 8 | |||
| 23 | 0x13 | 9 | |||
| 24 | 0x14 | 9 | |||
| 25 | 0x15 | 9 | |||
| 26 | 0x15 | 9 | |||
| 27 | 0x16 | 10 | |||
| 28 | 0x17 | 10 | |||
| 29 | 0x18 | 10 | |||
| 30 | 0x19 | 10 | |||
| 31 | 0x1b | 12 | |||
| 32 | 0x1c | 12 | |||
表5(本实施例中，只需要一个表，但是后一实施例表示了使用几个表的情况)具有46个条目，即行，每行由一个16位字组成，和如前所述在Tong(49字)或Hashemian(122字)中使用的表相比，空间较小。考虑到存在32个可能的代码字，这里效率为32/46＝69.6％。
出于举例说明的目的，表5的行被表示成依据“行#”栏编号，不过如表2中所示，当表5被实现成解码表222时，在存储空间中实际上并不存在该栏。在表5中，行0具有两个字段，本例中这两个字段包含值“2”和“13”。对于16位的总的行长度来说，这两个字段分别为8位。用负行号标记在行0上表示的各行，用正行号标记在行0下表面的各行。除行0之外的各行都具有三个字段。对于16位的总的行长度来说，这三个字段“条目标识符”、“符号/偏移地址”和“移位量/代码长度”分别为2、10和4位。
名为“条目标识符”的第一字段保存和三种可能情况相关的信息：
1)如果该字段包含“S”(用两个0位在存储器中表示的“找到符号指示符”，这里表示为“00”)，则该条目(即行)包含输出符号(即解码结果)及其长度。
2)如果该字段包含“B”(用“01”表示的“转向分支指示符”)，则该条目保存自表起始地址的偏移量。表4的表起始地址对应于行0的位置。偏移量被用于形成指向包含输出符号及其长度的存储条目的地址。即，偏移量被用于形成指向具有“S”作为其“条目指示符”的条目，即“S”条目的地址。
3)如果该字段包含“N”(用“10”表示的“下一表指示符”)，则该条目保存自表起始地址的偏移量，该偏移量被用于指向存储器224中别外的新表。另一方面，新表可被分路并被调换，以便替换前表。(本例中，并且如表5所示，不存在“N”条目，如本例后立即说明的那样)。
名为“符号/偏移地址”的第二字段可保存三种不同信息：
(1)输出符号(这里0x00～0x1f(是从0～31的十六进制数字)之一)，“0x”表示后面的符号是十六进制数字。
2)自表起始地址的偏移量。该偏移量用于形成指向当前代码字的输出符号的地址。
3)自表起始地址的偏移量。该偏移量用于形成指向新表起始地址的地址。(本例中，如表5中所示，不存在指向新表起始地址的任意条目)。
名为“移位量/代码长度”的第三字段能够保存两种信息。
1)它包含当前代码字必须向右移动到尾部偏移位的位置，以便形成指向输出符号的有效地址的数目。
2)它包含当前代码字的长度，在找到输出符号之后，当前代码字移位，以便移出当前代码字并移位新代码字的长度。
位于表起始位置的分支条目包含正分支计数和负分支计数，即在全0一侧存在两种可能分支(00和01)，在全1一侧存在13种可能的分支。在当前解码表的任意代码字中，正分支计数和负分支计数通常分别对应于连续0位和1位的最大数目，不过如下所述，可利用超过这些限制的代码字配置该表。
例如，如果输入的代码流包含4个代码字，“1111111110 00 01111011”，并在接收寄存器206中被接收：
1)主处理器208接收代码字寄存器中16位的当前组CURR_GRP，所述代码寄存器是非循环移位寄存器。加速器216从主处理器208接收16位的当前组CURR_GRP，在本例中，16位的当前组CURR_GRP必然包含当前代码字，因为如表4所示，最大代码字为13位。因此包含当前代码字加入后续代码字的多个位的CURR_GRP包含下述16位：“1111111110 00 01 11”。
这里，CURR_GRP包含前三个代码字和第四个代码字的一部分。首要任务是解码第一代码字，此时，第一代码字是当前代码字。
2)参见图3，加速器216检测到该组的前导位为1(步骤S302)，并返回值-9。量值9意味着在占据该组中的最高9位的连续1之后，加速器216检测到第一个0。负号意味着在步骤S302中检测的前导位的值为0。如果检测到的前导位为0，则返回的值为正。如果ACC_VALUE是返回值，或者计算器216返回当前计数值，则对于本例来说，ACC_VALUE＝-9(步骤S304)。
3)主处理器208检测ACC_VALUE的返回值是否有效。如果ZEROS_MAX和ONES_MAX分别代表正分支计数和负分支计数，，根据ACC_VALUE的符号，选择ZERO_MAX或ONES_MAX以便与ACC_VALUE比较，从而验证ACC_VALUE，即当ACC_VALUE为负，表示1位的计数时，只使用ONES_MAX。本例中，由于ACC_VALUE为负，检查ONES_MAX是否小于等于ACC_VALUE。表5显示13作为行0中负分支计数字段的内容。虽然被表示成不加符号以节约存储空间，不过负分支计数始终为负，因为ONES_MAX代表负分支计数，并且只有当ACC_VALUE为负时，才与ACC_VALUE比较。于是，本例中，负分支计数，从而ONES_MAX等于-13。由于-13小于等于-9，从而ONES_MAX小于等于ACC_VALUE。从而认为ACC_VALUE有效。
4)主处理器读取条目*(TABLE_STARTING_ADDRESS+ACC_VALUE)，这里TABLE_STARTING_ADDRESS指的是表起始地址，这里表起始地址位于行0。即位于行0+(-9)＝-9的表条目为：
| S | 0x1a | 10 |
将该条目复制到取回寄存器中(步骤S306)，取回寄存器306是非循环移位寄存器，这里*(ADDRESS)指的是位于ADDRESS的存储器位置的内容。参见表5，上述表条目位于TABLE_STARTING_ADDRESS上方的9个条目，因为ACC_VALUE＝9。
5)主处理器208检查该条目的“条目标识符”是为S、B还是N。为此，主处理器208将取回寄存器的内容复制到工作寄存器中。“符号/偏移地址”字段是该表中第二种类型的第二字段，如前所述。第二种类型指示可从由表起始地址、从该字段得到的偏移量和尾部偏移量之和指示的地址找到输出符号。下面，第二类“符号/偏移地址”字段将被称为“OFFSET”，其长度为10位，最右侧的字段为“移位量/代码长度”字段，其长度为4位。这些长度是不可变的，并且如上所述被选择成容纳其它设计参数。当前目标是确定最左侧字段“条目标识符”中的值。右移工作寄存器14位产生向右对齐“条目标识符”字段的效果，并用0填充最左侧的14位。值“S”、“B”和“N”驻留于它们相应存储单元的最右侧部分。于是，对工作寄存器移位简化了工作寄存器中“条目标识符”与各个相应存储单元的逐位比较，从而通过比较，“条目标识符”可被识别为值S、B和N之一。可按照任意顺序，例如与N，与S，随后与B比较的顺序进行所述比较。可选的是，可能只相对三个数值中的两个值进行比较，因为第三个值由消除过程确定。
6)移位工作寄存器与值“S”的比较表明，在当前例子中，“条目标识符”为“S”，这表示不需要另一次重复(步骤S308)，当前解码字已被解码(步骤S312)，于是，取回寄存器保存当前代码字的输出符号。
7)为了准备下一代码字，主处理器208检查“移位量/代码长度”条目，即取回寄存器的后4位，以便找出刚被解码的代码字的代码长度CW_LEN，本例中，CW_LEN为10。
8)取回寄存器被左移两位，以便清除长度为2位的“条目标识符”，随后被右移6位，以便清除移位量/代码长度字段(该字段为4位长，但是右移6位补偿向左侧的两位移位)，并向右对齐OFFSET，OFFSET包含呈输出符号形式的解码输出。如上在取回的条目中所示，本例中输出符号为“0x1a”。输出符号现在已被隔离，并在取回寄存器中被向右对齐，于是适用于解码输出的后续处理。
9)通过左移工作寄存器CW_LEN位(CW_LEN为10)，主处理器208准备对新的代码字解码。在本例中，位“1111111110”被左移出代码字寄存器。如果存在新的二进制位，则从右侧插入这些新的二进制位。本例中，从右侧移入“1011...”。省略号代表后续二进制位(如果存在的话)。于是，代码字寄存器包含“00 01 111011...”。如果不能从接收缓冲器206获得其它二进制位，例如当完成代码流的解码时，会不存在后续二进制位。如果代码字寄存器非空(步骤S318)，如同当前情况一样，则解码继续进行，使下一组成为当前组(步骤S310)。
10)CURR_GRP(当前情况下由当前组的前10位“00 01 111011”和达到16位寄存器限制的任意其它后续二进制位组成)准备好作为一组二进制位被发送给加速器216，以便对新的代码字解码，所述新的代码字现在被认为是当前代码字。
11)加速器216接收CURR_GRP(本例中为“00 01 111011”，如上面在步骤(9)中所示)。
12)加速器216返回ACC_VALUE＝3(即，当前计数值等于3)意味着在前三个“0”之后找到第一个“1”。
13)主处理器208检查ACC_VALUE是否小于等于ZEROS_MAX。
14)位于TABLE_STARTING_ADDRESS(它位于表5的行0)的最左侧字段为2。由于ACC_VALUE为3，因此ACC_VALUE小于等于ZEROS_MAX不成立，即ACC_VALUE超过界限。于是ACC_VALUE被设置成值ZEROS_MAX，这种情况下为2。
15)主处理器取读条目*(TABLE_STARTING_ADDRESS+ACC_VALUE)，即，位于行0+2＝2的条目，指向条目：
| S | 0x00 | 2 |
主处理器208将该条目复制到取回寄存器和工作寄存器中，如上面的步骤4和5那样。
16)主处理器208检查“条目标识符”字段，如上面的步骤5中那样，本例中，此时“条目标识符”包含“S”，于是，确定当前代码字已被解码(步骤308和S312)。
17)主处理器208抽取最后4位(如上面的步骤7中那样)，确定CW_LEN，本例中此时CW_LEN＝2。
18)主处理器208删除两个最高有效位，以便删除“条目标识符”字段，并右移OFFSET(其长度为4位)4+2＝6位，如上面的步骤8中那样，以便向右对齐输出符号，本例中所述输出符号为“0x00”。
19)代码字寄存器被左移CW_LEN位，如上面的步骤9中所示。本例中此时CW_LEN＝2位。新的二进制位被加入代码字寄存器的右侧。
20)现在，CURR_GRP包含“01 1110 11...”，因为在上面的步骤19中，刚被解码的两位已被移出代码字寄存器。
21)加速器216检测到该组的前导位为0(步骤S302)，返回值1。于是，ACC_VALUE＝1。
22)ACC_VALUE在界限内，因为ACC_VALUE小于等于ZEROS_MAX，所述ZEROS_MAX为2。
23)主处理器208检查*(TABLE_STARTING_ADDRESS+ACC_VALUE)，即位于行0+1的条目，并接收保存在取回寄存器和工作寄存器中的：
| S | 0x01 | 2 |
24)如上面的步骤5和6中那样，在被移位到工作寄存器的最低有效端之后，通过比较“条目标识符”被确定为“S”。
25)主处理器208检查取回寄存器的后4位，从“移位量/代码长度”字段接收值2。
26)输出符号是长度为2的“0x01”。进行如上所述的相同程序，以便准备下一代码字。
27)CURR_GRP＝“1110 11...”
28)ACC_VALUE＝-3。
29)ACC_VALUE在界限之内，因为ONES_MAX＝-13，ONES_MAX小于等于ACC_VALUE。
30)主处理器在*(TABLE_STARTING_ADDRESS+ACC_VALUE)读取表格，即位于行0+(-3)＝-3的条目，并接收保存在取回寄存器和工作寄存器中的：
| B | +9 | 14 |
31)如上面的步骤5和6中那样，在被移入工作寄存器的最低有效端之后，通过比较，“条目标识符”被确定为“B”。对于“B”条目，不需要另一次重复(步骤S308)，当前代码字还未被解码(步骤S312)。
32)主处理器208检查取回寄存器的后4位，从“移位量/代码长度”字段取回值14。该值将被用于确定临时寄存器(下面称为“TEMP”)向右移位，以便向右对齐尾部偏移位的位数，从而能够在下面的步骤35中增加尾部偏移量，形成指向输出符号的地址。
33)此时，主处理器208可将代码字寄存器左移1+ACC_VALUE的量值或者|ACC_VALUE|+1＝3+1＝4位，以便移出已计数的位行程和固有已知的尾位。但是，这里并不对代码字寄存器移位，因为“B”条目需要尾部偏移量，尾部偏移量向代码字加入二进制位，于是增大代码字的长度。代替此时将已使用的二进制位移出代码字寄存器，当完成当前代码字的解码并且取回代码字长度时，可立即移出整个当前代码字。本例中，在步骤38中移出代码字。
主处理器208将CURR_GRP保存在下面称为“TEMP”的临时寄存器中。虽然代码字寄存器未被左移|ACC_VALUE|+1位，但是TEMP被左移|ACC_VALUE|+1位。从而，消除位串“1110”。现在TEMP包含“11...”(保存在TEMP中的前导两位“11”包含步骤35中需要的尾部偏移位，其中TEMP被右移14位，从而位串“11”被右对齐。
34)主处理器208将取回寄存器移位到位于该寄存器的最低有效端，即最右端的位置OFFSET(即位4～13，这里位0是寄存器的最右侧的二进制位位置)，并确定OFFSET＝+9。
35)主处理器208在地址*(TABLE_STARTING_ADDRESS+OFFSET+(右移14的TEMP))，即地址*(TABLE_STARTING_ADDRESS+OFFSET+9+3)，即行0+9+3＝行12读取表格，并接收保存在取回寄存器中的条目(步骤S314-上面用于确定位于行12的条目位置的加数3是尾部偏移位“11”的值)：
| 0x0a | 6 |
36)主处理器208读取该条目的后4位，确定CW_LEN等于6。
37)主处理器208将该条目右移4位，右对齐符号“0x0a”。
38)代码字寄存器被左移CW_LEN(步骤S316)，如果存在新的二进制，则从右侧加入新的二进制位。当前情况下，不存在任何新的二进制位。
39)由于不存在可从接收缓冲器206获得的任何新二进制位(步骤S318)，处理暂停，直到由接收缓冲器206中二进制位的到达重新激活为止。
表5查寻表不具有字段标识符“N”，因为表5以其为基础的表4代码字是这样的，以致计数之后的任意代码字的剩余部分，即除了与紧接其后的并且固有已知的二进制位组合的位行程之外的部分的长度总是两位或者更少。于是，通过设计，这些两位或者更少位被立即评估为表5中的预定尾部偏移量，因为是首次并且是最后一次重复。于是，第一例子没有充分显示本发明的0和1串的递推计数的潜力。
本发明的例证第二实施例证明了关于前导1和0的搜索中的重复。类似于第一实施例，在图1～3中举例说明了第二实施例，但是第二实施例以通过修改取自Mp3音频标准的“Huffman Table Number 13”得到的表为基础。下表6中表示了该修改表。
表6
符号 码字 符号 码字
1 1 45 0001001010
2 011 46 0001001001
3 0101 47 0001001000
4 0100 48 0001000111
5 001111 49 0001000110
6 001110 50 000100010
7 001101 51 000100001
8 001100 52 0001000001
9 0010111 53 0001000000
10 0010110 54 000011111
11 0010101 55 000011110
12 0010100 56 000011101
13 0010011 57 00001110011
14 00100101 58 00001110010
15 00100100 59 0000111000
16 00100011 60 0000110111
17 00100010 61 0000110110
18 0010000 62 0000110101
19 00011111 63 0000110100
20 000111101 64 000011001
21 000111100 65 000011000
22 000111011 66 00001011111
23 000111010 67 00001011110
24 000111001 68 00001011101
25 000111000 69 00001011100
26 00011011 70 00001011011
27 00011010 71 00001011010
28 000110011 72 0000101100
29 000110010 73 0000101011
30 000110001 74 00001010101
31 0001100001 75 00001010100
32 0001100000 76 0000101001
33 000101111 77 0000101000
34 000101110 78 00001001111
35 000101101 79 00001001110
36 000101100 80 00001001101
37 000101011 81 00001001100
38 000101010 82 0000100101
39 00010100 83 00001001001
40 0001001111 84 00001001000
41 0001001110 85 0000100011
42 0001001101 86 00001000101
43 0001001100 87 00001000100
44 0001001011 88 0000100001
符号 码字 符号 码字
89 0000100000 136 000000101110
90 0000011111 137 000000101101
91 0000011110 138 000000101100
92 00000111011 139 00000010101
93 00000111010 140 000000101001
94 00000111001 141 0000001010001
95 00000111000 142 0000001010000
96 00000110111 143 000000100111
97 00000110110 144 0000001001101
98 00000110101 145 0000001001100
99 00000110100 146 0000001001011
100 0000011001 147 0000001001010
101 0000011000 148 000000100100
102 0000010111 149 000000100011
103 000001011011 150 000000100010
104 000001011010 151 000000100001
105 00000101100 152 0000001000001
106 000001010111 153 0000001000000
107 000001010110 154 000000011111
108 00000101010 155 000000011110
109 000001010011 156 0000000111011
110 000001010010 157 0000000111010
111 00000101000 158 0000000111001
112 000001001111 159 0000000111000
113 000001001110 160 0000000110111
114 00000100110 161 0000000110110
115 00000100101 162 0000000110101
116 000001001001 163 0000000110100
117 000001001000 164 0000000110011
118 000001000111 165 0000000110010
119 000001000110 166 0000000110001
120 00000100010 167 0000000110000
121 000001000011 168 000000010111
122 000001000010 169 000000010110
123 00000100000 170 0000000101011
124 00000011111 171 0000000101010
125 000000111101 172 000000010100
126 000000111100 173 0000000100111
127 00000011101 174 0000000100110
128 00000011100 175 0000000100101
129 00000011011 176 0000000100100
130 00000011010 177 0000000100011
131 000000110011 178 0000000100010
132 000000110010 179 000000010000
133 000000110001 180 000000001111
134 000000110000 181 000000001110
135 000000101111 182 00000000110111
符号 码字 符号 码字
183 00000000110110 230 000000000001111
184 0000000011010 231 000000000001110
185 0000000011001 232 000000000001101
186 00000000110001 233 000000000001100
187 00000000110000 234 000000000001011
188 0000000010111 235 000000000001010
189 00000000101101 236 000000000001001
190 00000000101100 237 0000000000010001
191 0000000010101 238 0000000000010000
192 00000000101001 239 000000000000111
193 00000000101000 240 000000000000110
194 0000000010011 241 00000000000010111
195 00000000100101 242 00000000000010110
196 00000000100100 243 0000000000001010
197 0000000010001 244 0000000000001001
198 0000000010000 245 0000000000001000
199 00000000011111 246 0000000000000111
200 00000000011110 247 0000000000000110
201 0000000001110 248 0000000000000101
202 00000000011011 249 0000000000000100
203 000000000110101 250 0000000000000011
204 000000000110100 251 0000000000000010
205 00000000011001 252 0000000000000001
206 00000000011000 253 00000000000000001
207 00000000010111 254 000000000000000001
208 00000000010110 255 0000000000000000001
209 00000000010101 256 0000000000000000000
210 00000000010100
211 00000000010011
212 00000000010010
213 00000000010001
214 00000000010000
215 00000000001111
216 000000000011101
217 000000000011100
218 000000000011011
219 000000000011010
220 00000000001100
221 00000000001011
222 0000000000101011
223 0000000000101010
224 000000000010100
225 0000000000100111
226 0000000000100110
227 000000000010010
228 000000000010001
229 000000000010000
而取自Mp3音频标准的Huffman Table Number 13使每个代码字与一个数字对联系起来，出于简化起见，上表6向每个代码字分配选自范围“1”～“256”的一个相应符号。另外出于简化起见，具有相同前导位的代码字被分为一组，从而它们的相应符号是连续的。如同在HuffmanTable Number 13中一样，表6中任意代码字的最大长度为19位。
下面所示的表7和8是基于表6的多个解码表中的两个解码表，在本实施例中共同使用这两个解码表解码需要多次计数，即需要多次重复S302～S310循环的代码字。这里只提供了这两个表7和8，因为解码本例中的串只需要表7和8。表7是主解码表，表8是子表。另外，表7具有多个其它子表，子表可具有它们自己的子表。对于运行速度来说，所有这些(子)表最好驻留在存储器中，为了简洁起见，这些(子)表最好彼此相邻。从而，主表之后是子表，子表之后是它自己的子表，之后是主表的第二子表，以及第二子表的子表等等。
表7例证的查寻表
| 行# | 条目标识符 | 符号/偏移地址 | 移位量/代码长度 | |
| -1 | S | 0x1 | 1 | |
| 0 | 19 | 1 | ||
| 1 | B | +20 | 17 | |
| 2 | N | T1 | ||
| 3 | N | T2 | ||
| 4 | N | T3 | ||
| 5 | N | T4 | ||
| 6 | N | T5 | ||
| 7 | N | T6 | ||
| 8 | N | T7 | ||
| 9 | N | T8 | ||
| 10 | N | T9 | ||
| 11 | N | T10 | ||
| 12 | N | T11 | ||
| 13 | B | +24 | 17 | |
| 14 | B | +28 | 18 | |
| 15 | S | 0xFC | 16 | |
| 16 | S | 0xFD | 17 | |
| 17 | S | 0xFE | 18 | |
| 18 | 0xFF | 19 | ||
| 19 | 0x100 | 19 | ||
| 20 | 0x4 | 4 | ||
| 21 | 0x3 | 4 | ||
| 22 | 0x2 | 3 | ||
| 23 | 0x2 | 3 | ||
| 24 | 0xF6 | 16 | ||
| 25 | 0xF7 | 16 | ||
| 26 | 0xF8 | 16 | ||
| 27 | 0xF9 | 16 | ||
| 28 | 0xFA | 16 | |
| 29 | 0xFB | 16 |
表8例证的查寻子表T2
| 行# | 条目标识符 | 符号/偏移地址 | 移位量/代码长度 | |
| -4 | S | 0x13 | 8 | |
| -3 | B | +11 | 18 | |
| -2 | B | +7 | 17 | |
| -1 | N | T2_1 | ||
| 0 | 6 | 5 | ||
| 1 | N | T2_2 | ||
| 2 | B | +13 | 16 | |
| 3 | B | +21 | 17 | |
| 4 | S | 0x33 | 10 | |
| 5 | S | 0x34 | 10 | |
| 6 | S | 0x35 | 9 | |
| 7 | 0x19 | 9 | ||
| 8 | 0x18 | 9 | ||
| 9 | 0x17 | 9 | ||
| 10 | 0x16 | 9 | ||
| 11 | 0x15 | 9 | ||
| 12 | 0x14 | 9 | ||
| 13 | 0x2f | 10 | ||
| 14 | 0x2e | 10 | ||
| 15 | 0x2d | 10 | ||
| 16 | 0x2c | 10 | ||
| 17 | 0x2b | 10 | ||
| 18 | 0x2a | 10 | ||
| 19 | 0x29 | 10 | ||
| 20 | 0x28 | 10 | ||
| 21 | 0x32 | 9 | ||
| 22 | 0x32 | 9 | ||
| 23 | 0x31 | 10 | ||
| 24 | 0x30 | 10 | ||
和前一例子中的解码表(表5)不同，表7是具有“条目标识符”为“N”的条目的解码表，每个“N”条目指向一个新的解码表。例如，表7的行3具有指向子表T2(如上表8中所示)的“符号/偏移地址”字段。表8的后续各行指向其它子表(未示出)。在对代码字解码的过程中，当需要另一计数，从而需要再次重复循环S302～S310时，处理转移到子表。
这里假定从编码位流源202接收的是下述位串“0001000111...”，这里省略号代表位串中的后续二进制位。
如下进行下述位串0001000111的解码：
1)CURR_GRP＝0001000111...(多达19位，这是本实施例中的搜索字段长度，因为表6具有19位的最大代码长度)。
2)ACC_VALUE＝3(参见图3，步骤S302和S304)，因为高阶串由3位组成，即“000”。根据ACC_VALUE为正或负，分别依据ZEROS_MAX或ONES_MAX验证ACC_VALUE。由于本例中，ACC_VALUE取正值，因此ZEROS_MAX被用于验证。ZEROS_MAX和ONES_MAX通常分别被设置成等于正分支量和负分支量，如本例中的情况那样，并且如前一例子中的情况那样。正分支量被设置成等于解码中需要的最大零位计数。由于表7中的符号“255”由19个0组成，因此正分支量被设置成19，如行0中所示。因此，ZEROS_MAX＝19。
由于ZEROS_MAX为19，并且ACC_VALUE为3，ACC_VALUE小于等于ZEROS_MAX；于是，ACC_VALUE在界限内。
3)表7当前位置是TABLE_STARTING_ADDRESS(行0)。使表7中ACC_VALUE＝3的偏移量从当前位置到达行3。随后取回行3的内容。象征性地，*(TABLE_STARTING_ADDRESS+ACC_VALUE)为：
| N | T2 |
主处理器208将该条目复制到取回寄存器和工作寄存器中。
4)主处理器208通过对工作寄存器移位，检查条目标识符，并确定条目标识符为N，意味着将产生到达新表的分支，所述新表位于TABLE_STARTING_ADDRESS+OFFSET。由于标识符为N，需要再次重复(步骤S308)。
5)主处理器208将条目标识符字段移出取回寄存器，留下包含值“T2”的第二字段。第二字段是前面指出的第三种类型，即它包含从TABLE_STARTING_ADDRESS到新表(子表T2，所述子表T2是表8)的偏移量(注意表8中的行-1和1在“符号/偏移地址”字段中分别包含“T2_1”和“T2_2”。“T2_X”是子表T2的子表的地址，即表8的子表的地址)。
6)如果TABLE_STARTING_ADDRESS还未被保存为主处理器208执行的程序的说明参数以便快速取回，则在将TABLE_STARTING_ADDRESS保存为ADDRESS_SAVE之后，更新TABLE_STARTING_ADDRESS＝TABLE_STATRING_ADDRESS+T2。现在，TABLE_STARTING_ADDRESS指向为始于“0001”(已被用于调用表8的前导代码字位)的代码字产生的表8。
7)TEMP(类似于CURR_GRP，在实施例中为19位长)装着CURR_GRP，并被左移|ACC_VALUE|+1位。从而已知的4位被移离。
8)TEMP＝“000111...”中的剩余位现在包含输入加速器216的CURR_GRP(步骤S312)。
9)由于长度为3的高阶位行程的缘故，ACC_VALUE＝3(步骤S302和S304)。
10)主处理器208取回*(TABLE_STARTING_ADDRESS)，
| 0 | 6 | 5 |
现在它对应于表8的行0条目。主处理器208现在具有用于与ACC_VALUE比较的正分支计数。
11)ACC_VALUE在界限内(因为这里正分支计数为6)。
12)主处理器208读取*(TABLE_STARTING_ADDRESS+ACC_VALUE)，得到：
| B | +21 | 17 |
主处理器208将该条目复制到取回寄存器和工作寄存器中。
13)主处理器208对工作寄存器移位，将该条目识别为“B”条目。对于“B”条目来说，不需要再次重复(步骤S308)，当前代码字未被解码(步骤S312)。在检测取回寄存器中“移位量/代码长度”中的数值之后，主处理器208通过对取回寄存器移位，确定位4～13(即由OFFSET表示的符号/偏移地址字段)。
14)主处理器208将CURR_GRP，即代码字寄存器的内容复制到TEMP，并将TEMP左移|ACC_VALUE|+1位。现在TEMP包含位串“11......”。通过右移TEMP 17位(这是本例中在“移位量/代码长度”中规定的位数)，在TEMP中右对齐位串“11”。在该最后重复中，位串“11”的值用作表8中的预定尾部偏移量。
15)主处理器208读取*(TABLE_STARTING_ADDRESS+OFFSET+(依据上面在步骤14中规定的SHIFT右移之后的TEMP))，即，内容或行(0+21+3＝34)，得到条目：
| 0x30 | 10 |
主处理器208将该条目复制到取回寄存器中(步骤S314)。
16)主处理器208从4个最低有效位抽取CL_LEN＝10。
17)主处理器将该条目右移4位，并接收输出符号(所述输出符号是十六进制数值“30”，或十进制数值48)。如表6所示，和预期一样，输出符号“48”对应本例中解码的代码字“0001000111”。
18)CURR_GRP被左移CL_LEN(步骤S316)。如果当前在接收缓冲器206中存在任意新的二进制位，则所述新的二进制位填充代码字寄存器一直到19位的搜索字段长度。
19)从ADDRESS_SAVE恢复TABLE_STARTING_ADDRESS。
20)如果代码流未完成，则继续进行解码(步骤S318)。
注意如果始于特定位序列的任意代码字需要使用子表，则在解码过程中，所有这些代码字都需要子表。通过确定前导子串“000”的为3的计数，忽略下一二进制位，并使用最后的三位“100”作为尾部偏移量，解码代码字“0001100”，只要尾部阈值至少为3。在不具有更多信息的情况下，设计主解码表，从而计数3移入表中，指向“B”条目，从而允许使用尾部偏移量；从而，找到输出符号，不需要任意子表。但是，如果始于“001”的另一代码字需要子表，则前导串“001”会引向“B”条目，而不是引用所需子表的所需“N”条目。一个例子是“00101100”。该代码字起始于子串“001”，该子串带来1位行程计数，但是代码字需要每个后续位行程计数的子表。
解决方案是设计主解码表，以致前导子串“001”指向“N”条目，而不是指向“B”条目，并构成转向子表的分支，以便应付此时的处理。从而，任意代码字的前导串“001”使处理指向主解码表中的“N”条目。
在霍夫曼代码字的解码中，正分支计数和负分支计数被反复用于验证位行程计数，但是对于特定的解码表来说是固定的。开始解码时，最好将它们保存在例如特定的CPU寄存器中，以便快速存取，从而避免反复从表中取回它们的开销。
正分支计数和负分支计数可被局限于除某一计数所需的最大数目的连续0和1位之外的某一长度。例如，代替查看19位，仅仅检查前16位。这种情况下，位于TABLE_STARTING_ADDRESS+(ZEROS_MAX或ONES_MAX)的表条目包含相对于新表的指针，所述新表处理长于16位的代码字的剩余二进制位。但是，为了使解码时间保持最小，要计数的大部分位行程应放入解码器窗口，在第一实施例中，所述解码器窗口为16位，在第二实施例中，所述解码器窗口为19位。
尾部阈值的长度是一个设计问题。在第一解码例子中，该长度为2位。使用1位不会节省存储器，但是会需要更多的递归步骤，于是需要更长的解码时间，不过1位可能对其它解码表有利。而在第一实施例中，将尾部阈值增大到3不会有所裨益，因为所有子树具有2位(在处理0/1串之后)的最大剩余代码字长度，诸如3或4之类不同阈值可用于更复杂的表，例如在JPEG或MPEG标准中采用的那些表，为3的尾部阈值被用于第二实施例。更多的二进制位提供更快速的搜索，但是会导致具有数个冗余存储单元的解码表。例如，三个剩余位(对于为3的尾部阈值来说)需要8个存储单元，虽然情况可能是代码字只占据其中的三个存储单元。
这里给出的解码表中的字段大小是可变的，从而如果需要较长的解码表行，则可调整字段的相对长度，或者可使用更长的字长度。10位的符号/偏移地址字段大小能够对RAM 224中的1024个存储单元编址，这足以满足第一或第二实施例。例如，在第二实施例中，表6包含256个符号，而即使效率仅为50％，也只存在512个需要引用的不同存储单元。在第一实施例中，表4只具有32个符号，易于被10位存储器地址容纳。
在第一实施例中，移位量/代码长度字段为4位，允许处理长度多达16位的代码字；而第二实施例使用5位长的移位量/代码长度字段，因为最大代码字长度为19位，这可由5位来表示。解码表中最终得到的总条目长度为17位-2位用于条目标识符字段，10位用于符号/偏移地址，5位用于移位量/代码长度字段。另一方面，通过从符号/偏移地址字段中消除1位，相应地通过使某些子表不驻留并调换到存储器中，减小RAM存储器224，可使总的条目长度为16位。
对于特定的霍夫曼树来说，查寻表可以是固定的。另一方面，可在开始解码时，根据引入编码位流中的霍夫曼树“在传输过程中”产生查寻表，或者根据需要更新查寻表，以便适应自适应霍夫曼编码方案。
虽然表示的实施例具有带有“B”条目的解码表，并使用尾部偏移量，但是本发明的范围并不要求解码表具有“B”条目，或者要求使用尾部偏移量。例如，解码表可以只具有“S”和“N”条目—“S”条目包含解码的输出符号，而“N”条目指向后续的解码表。操作中，当前代码字中的每个位行程导致相应的计数，主处理器208根据相应的计数，确定当前表中的相应偏移量。在该偏移量下，相应的“N”条目指向相应的后续子表，对下一位行程重复该过程，直到根据最后的位行程，主处理器208移入当前表，到达“S”条目，所述“S”条目包含解码结果。
最好利用加速器216实现本发明，以帮助CPU难以完成的困难的位处理功能，例如查找0/1串的长度，位移位和比较。例如，如上所述，难以利用软件找出流中的第一个“1”，但是通过硬件易于找出流中的第一个“1”。
图4根据本发明，图解说明了霍夫曼解码设备400中，前导1/0计数计算器或加速器404的一种可能实现。这里关于8位搜索窗口说明操作：寄存器412中的主CPU 410将要检测的二进制位部分作为当前一组二进制位408的一部分提供给加速器404。要搜索的第一位位于寄存器的MSB端。输入的位片的MSB或前导位414由具有值检测器417的选择器416检查，以便确定处理向“全0”路径前进还是向“全1”路径前进。如果在MSB 414检测到预先选择的位值，例如1，则第一反相器418逐位反转寄存器412的输出，否则，如果0是MSB 414，则不进行反转。在任意一种情况下，选择器416将结果传递给数字扩展器，例如1扩展器419，1扩展器419将数字扩展输出420中，有效性低于具有预定值的最高有效位的每个其它取值的二进制位转换成预定值，这里转换成1。第二反相器422反转输出420。
第二反转结果由倒转器(reversor)424倒转，从而位xL与x0交换，xL-1与x1交换，依次类推，这里xL是最高有效位，x0是最低有效位。该倒转结果，即倒转串被引向thermometer代码评估器426，所述评估器426对二进制编码数字转换进行thermometer，从而确定全0/1行程的长度。thermometer代码是在一端具有所有相同取值的二进制位的位串，取值相同的二进制位的数目表示代码的值，即具有4个尾随1的thermometer代码具有为4的值。如果值检测器417检测到前导位414具有预定值，则包括非元件430和选择器432的行程表征器428对thermometer代码评估器426的输出求反。从而，行程表征器428有选择地对thermometer代码评估器的输出重新格式化，包括将该输出符号扩展到主CPU 410的自然长度的步骤(如果主CPU 410需要这种扩展)。
最终结果是给出位于当前组408起点的全1/0行程的长度，即组408的当前计数值。如果前导位414为1，则最终结果为负，如果前导位414为0，则最终结果为正。
可用于加速器404的硬件的例子如下所示(使用16位搜索字段，因为16位是CPU的常见自然字长度)。
1)保存要搜索的数据的16位寄存器412；
2)反转数据的16个NOT门(如果需要反转)；
3)32-16选择器416；
4)向右扩展第一个检测到的1的硬件；
5)反转该结果的16个NOT门；
6)倒转16位的硬件；
7)Thermometer/BCD转换器(16-4 BCD编码器)；
8)BCD/-2的补数转换器(非门430)；
9)选择直接求反结果或2的补数求反结果的32-16选择器(选择器432)；
10)输出缓冲器寄存器，16位。
“对于1来说为负，对于0来说为正”的约定不是必需的。可按照某一其它形式将信息传送给CPU。在上面的实施例中，加速器输出的格式提供当前计数值和选择ONES_MAX或ZEROS_MAX以便与ACC_VALUE比较的基础。但是，存在几种其它方法，例如传送结果的MSB端中的全1信息和LSB端中的全0信息，这样就不需要BCD/2的补数转换，相应地不需要thermometer评估器426。
在备选实施例中，如果允许加速器404进入主CPU 410的核心，则借助主CPU已具有的寄存器，可实现与主机的接口。
虽然参考霍夫曼编码代码字说明了上述实施例，不过本发明的范围包括其它可变长度代码字。
从而，虽然表示、说明和指出了当应用于其优选实施例时，本发明的基本新特征，不过在不脱离本发明的精神的情况下，本领域的技术人员显然可对举例说明的设备的形式和细节，及其操作做出各种省略、替换和改变。例如，按照基本相同的方式实现基本相同的功能，获得相同结果的这些部件和/或方法步骤的所有组合显然都在本发明的范围内。此外，应认识到结合本发明的任意公开形式或实施例表示和/或说明的结构和/或部件和/或方法可作为设计选择的一般内容包含在任意其它公开的或说明的或建议的形式或实施例中。于是，本发明的范围只由附加权利要求的范围所限定。
Claims (29)
1、一种用于对一系列可变长度代码字中的当前代码字解码的方法，包括：
a)检测所述代码字中某一位的值；
b)计算始于所述位、并且包含所述相同值的后续连续位的当前计数值；
c)根据所述当前计数值，从解码表取回一个条目；和
d)对包含在步骤(b)中的一个或多个计数值中的那些位之后的位重复步骤(a)～(c)，直到最后取回的条目指出不需对所述当前代码字重复步骤(a)～(c)为止。
2、按照权利要求1所述的方法，在步骤(d)之后还包括下述步骤：
e)确定最后取回的条目是否包含构成所述当前代码字的解码的输出符号；
f)如果否，则根据在步骤b)中计数的那些位之后的至少一位，从解码表取回包含构成所述当前代码字的解码的输出符号的条目。
3、按照权利要求1所述的方法，其中步骤c)还包括检测所述条目是否包含找到符号指示符，其中所述找到符号指示符的检测表示不需重复步骤(a)～(c)。
4、按照权利要求1所述的方法，其中步骤c)还包括检测所述条目是否包含转移指示符，其中所述转移指示符的检测指示不需重复步骤(a)～(c)。
5、按照权利要求4所述的方法，在步骤(c)之后还包括下述步骤：
e)如果检测到所述转移指示符，则根据在步骤b)中计数的那些位之后的至少一位，从解码表中取回包含构成所述当前代码字的解码的输出符号的条目。
6、按照权利要求5所述的方法，其中对于步骤(f)来说，所述至少一位属于所述当前代码字，并且由不大于预定阈值的多个位组成。
7、按照权利要求1所述的方法，其中所述方法对相应迭代的检测位值并不都相同的当前代码字解码。
8、按照权利要求1所述的方法，其中步骤(c)中的取回是从因迭代而异的不同解码表的取回。
9、按照权利要求1所述的方法，其中利用所述一系列代码字中的单一二进制位逐次迭代地分离计数二进制位。
10、按照权利要求1所述的方法，其中所述一系列的可变长度代码字由移动终端接收，并由所述方法解码。
11、按照权利要求10所述的方法，其中所述移动终端是移动电话机。
12、按照权利要求1所述的方法，其中所述可变长度代码字是霍夫曼编码代码字。
13、一种对连续排列的可变长度代码字解码的可变长度解码设备，包括：
前导0/1计数计算器，用于检测所接收的代码字中二进制位的值，并计算始于所述二进制位、并包含所述相同值的后续连续二进制位的当前计数值；和
根据当前计数值而从解码表取回条目的控制部件，所述控制部件还被配置成对于所述计算器计数的那些二进制位之后的二进制位，重复调用所述计算器并在每次迭代中执行所述取回步骤，直到最后取回的条目指示对于当前代码字无需重复调用和执行步骤为止。
14、按照权利要求13所述的设备，所述控制部件还被配置成确定最后取回的条目是否包含构成所述当前代码字的解码的输出符号，如果否，则根据在步骤b)中计数的那些二进制位之后的至少一个二进制位，从解码表取回包含构成所述当前代码字的解码的输出符号的条目。
15、按照权利要求14所述的设备，其中所述至少一个二进制位属于所述当前代码字，并由不大于预定阈值的多个位组成。
16、按照权利要求15所述的设备，其中所述设备是可操作的，以致相应迭代的所述检测位值通常并不都相同。
17、按照权利要求13所述的设备，其中所述设备被配置成使得相应迭代的所述检测位值通常并不都相同。
18、按照权利要求13所述的设备，其中所述迭代取回是自因迭代而异的不同解码表的取回。
19、按照权利要求13所述的设备，还包括从所述控制部件接收所述当前代码字的解码的移动终端。
20、按照权利要求19所述的设备，其中所述移动终端是移动电话机。
21、按照权利要求13所述的设备，其中所述可变长度代码字是霍夫曼编码代码字。
22、一种确定位串的前导位的值以及包含所述位的行程的计数值的设备，包括：
检测所述值的值检测器；
如果所述检测值等于预定位值，则反转所述位串的二进制位的第一反相器；
数字转换器，用于将值不同于所述预定位值、并且有效性低于具有所述预定位值的最高有效位的所述位串的每一位转换成所述预定位值；
反转来自所述数字转换器的位输出的第二反相器；
倒转器，用于倒转所述第二反相器反转的所述二进制位的顺序，以产生倒转位串；和
thermometer代码评估器，用于计算所述倒转位串中具有所述预定值的二进制位的行程计数值。
23、按照权利要求22所述的设备，还包括：
从连续排列的可变长度代码字中选择所述位串的装置；和
使用所述计算的行程计数值和检测值，对所述代码字的当前代码字解码的装置。
24、按照权利要求23所述的设备，其中所述可变长度代码字是霍夫曼编码代码字。
25、按照权利要求22所述的设备，还包括汇编所述计算的行程计数值数字表示和所述检测值的行程表征器。
26、按照权利要求25所述的设备，其中所述数字表现包括所计算的计数值的二进制编码的十进制表示。
27、一种对连续排列的可变长度代码字解码的指令的计算机可读介质，包括：
a)检测所述代码字中某一位的值的单元；
b)计算始于所述位、并包括所述相同值的后续连续位的当前计数值的单元；
c)根据当前计数值，从解码表取回某一条目的单元；和
d)对装置(b)计数的那些位之后的二进制位，在每次迭代中重复调用装置(a)～(c)，直到最后取回的条目指出对于所述当前代码字不需重复调用装置(a)～(c)为止的单元。
28、按照权利要求24所述的介质，还包括：
e)确定最后取回的条目是否包含所述当前代码字的解码的单元；
f)如果装置e)确定还未取回所述当前代码字的解码，则根据在装置b)计数的那些位之后的至少一位，从解码表取回包含所述当前代码字的解码的条目的单元。
29、一种确定位串的前导位的值并且包含所述位的行程的计数值的方法，包括：
检测所述值；
如果所述检测值等于预定位值，则反转所述位串的二进制位；
将值不同于所述预定位值，并且有效性低于具有所述预定位值的最高有效位的所述位串的每一位转换成所述预定位值；
反转所述转换后的位串；
倒转在所述转换之后反转的所述二进制位的顺序，产生倒转位串；和
计算所述倒转位串中，具有所述预定值的二进制位的行程计数。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/045,693 US6563440B1 (en) | 2001-10-19 | 2001-10-19 | Apparatus and method for decoding Huffman codes using leading one/zero string length detection |
| US10/045,693 | 2001-10-19 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1613188A true CN1613188A (zh) | 2005-05-04 |
| CN100477532C CN100477532C (zh) | 2009-04-08 |
Family
ID=21939355
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB028198115A Expired - Fee Related CN100477532C (zh) | 2001-10-19 | 2002-10-11 | 霍夫曼编码方法和设备 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US6563440B1 (zh) |
| EP (1) | EP1436899A1 (zh) |
| KR (1) | KR100950607B1 (zh) |
| CN (1) | CN100477532C (zh) |
| WO (1) | WO2003034597A1 (zh) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102237878A (zh) * | 2010-04-20 | 2011-11-09 | 慧荣科技股份有限公司 | 一种霍夫曼解码方法 |
| CN101406014B (zh) * | 2006-10-18 | 2012-04-25 | 株式会社石田 | 编码装置、脉冲再现装置和通信系统 |
| CN104253993A (zh) * | 2013-06-28 | 2014-12-31 | 炬力集成电路设计有限公司 | 一种多媒体数据处理方法、电路及装置 |
| CN104283568A (zh) * | 2013-07-12 | 2015-01-14 | 中国科学院声学研究所 | 一种基于部分霍夫曼树的数据压缩编码方法 |
| CN104717499A (zh) * | 2015-03-31 | 2015-06-17 | 豪威科技(上海)有限公司 | 一种霍夫曼表的存储方法及用于jpeg的霍夫曼解码方法 |
| CN106560010A (zh) * | 2014-06-09 | 2017-04-05 | 泰德系统股份有限公司 | Vlsi高效霍夫曼编码设备和方法 |
| CN113271107A (zh) * | 2020-09-30 | 2021-08-17 | 北京清微智能科技有限公司 | 一种Huffman硬件解码方法 |
Families Citing this family (32)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6704645B1 (en) * | 2001-12-11 | 2004-03-09 | Garmin Ltd. | System and method for estimating impedance time through a road network |
| US6574554B1 (en) * | 2001-12-11 | 2003-06-03 | Garmin Ltd. | System and method for calculating a navigation route based on non-contiguous cartographic map databases |
| US6650996B1 (en) | 2001-12-20 | 2003-11-18 | Garmin Ltd. | System and method for compressing data |
| US6581003B1 (en) * | 2001-12-20 | 2003-06-17 | Garmin Ltd. | Systems and methods for a navigational device with forced layer switching based on memory constraints |
| US6975940B1 (en) | 2001-12-21 | 2005-12-13 | Garmin Ltd. | Systems, functional data, and methods for generating a route |
| US7184886B1 (en) * | 2001-12-21 | 2007-02-27 | Garmin Ltd. | Navigation system, method and device with detour algorithm |
| CN1314271C (zh) * | 2003-09-09 | 2007-05-02 | 华为技术有限公司 | 一种视频编解码方法 |
| US6903669B1 (en) * | 2003-10-03 | 2005-06-07 | Cirrus Logic, Inc. | Systems and methods for decoding compressed data |
| KR101142584B1 (ko) * | 2003-11-18 | 2012-05-10 | 스칼라도 아베 | 디지털 이미지 처리 방법 및 이미지 표현 포맷 |
| KR20050053996A (ko) * | 2003-12-03 | 2005-06-10 | 삼성전자주식회사 | 허프만 코드를 효율적으로 복호화하는 방법 및 장치 |
| US8427494B2 (en) * | 2004-01-30 | 2013-04-23 | Nvidia Corporation | Variable-length coding data transfer interface |
| US7148821B2 (en) * | 2005-02-09 | 2006-12-12 | Intel Corporation | System and method for partition and pattern-match decoding of variable length codes |
| US7925320B2 (en) | 2006-03-06 | 2011-04-12 | Garmin Switzerland Gmbh | Electronic device mount |
| US8254700B1 (en) | 2006-10-03 | 2012-08-28 | Adobe Systems Incorporated | Optimized method and system for entropy coding |
| WO2008142800A1 (ja) * | 2007-05-24 | 2008-11-27 | Fujitsu Limited | 情報検索プログラム、該プログラムを記録した記録媒体、情報検索装置、および情報検索方法 |
| WO2008142799A1 (ja) * | 2007-05-24 | 2008-11-27 | Fujitsu Limited | 情報検索プログラム、該プログラムを記録した記録媒体、情報検索方法、および情報検索装置 |
| US8725504B1 (en) | 2007-06-06 | 2014-05-13 | Nvidia Corporation | Inverse quantization in audio decoding |
| US8726125B1 (en) | 2007-06-06 | 2014-05-13 | Nvidia Corporation | Reducing interpolation error |
| US8477852B2 (en) * | 2007-06-20 | 2013-07-02 | Nvidia Corporation | Uniform video decoding and display |
| US8849051B2 (en) * | 2007-09-17 | 2014-09-30 | Nvidia Corporation | Decoding variable length codes in JPEG applications |
| US8502709B2 (en) * | 2007-09-17 | 2013-08-06 | Nvidia Corporation | Decoding variable length codes in media applications |
| US8704834B2 (en) * | 2007-12-03 | 2014-04-22 | Nvidia Corporation | Synchronization of video input data streams and video output data streams |
| US8687875B2 (en) * | 2007-12-03 | 2014-04-01 | Nvidia Corporation | Comparator based acceleration for media quantization |
| US8934539B2 (en) * | 2007-12-03 | 2015-01-13 | Nvidia Corporation | Vector processor acceleration for media quantization |
| US9307267B2 (en) * | 2008-12-11 | 2016-04-05 | Nvidia Corporation | Techniques for scalable dynamic data encoding and decoding |
| KR101175680B1 (ko) * | 2008-12-23 | 2012-08-22 | 광운대학교 산학협력단 | 비트스트림 프로세서의 구동방법 |
| KR101843087B1 (ko) * | 2012-03-05 | 2018-03-28 | 삼성전자주식회사 | 디코딩 장치 및 방법 |
| US9298420B2 (en) * | 2013-07-26 | 2016-03-29 | International Business Machines Corporation | Identification of the bit position of a selected instance of a particular bit value in a binary bit string |
| US9787323B1 (en) | 2016-12-11 | 2017-10-10 | Microsoft Technology Licensing, Llc | Huffman tree decompression |
| TWI645698B (zh) * | 2017-07-17 | 2018-12-21 | 財團法人工業技術研究院 | 資料發送裝置、資料接收裝置及其方法 |
| US11475061B2 (en) * | 2018-09-12 | 2022-10-18 | Samsung Electronics Co., Ltd. | Method and device for detecting duplicate content |
| KR102687153B1 (ko) * | 2019-04-22 | 2024-07-24 | 주식회사 쏠리드 | 통신 신호를 처리하는 방법 및 이를 이용하는 통신 노드 |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4396906A (en) * | 1980-10-31 | 1983-08-02 | Sri International | Method and apparatus for digital Huffman encoding |
| US5181031A (en) | 1991-07-30 | 1993-01-19 | Lsi Logic Corporation | Method and apparatus for decoding huffman codes by detecting a special class |
| US5208593A (en) | 1991-07-30 | 1993-05-04 | Lsi Logic Corporation | Method and structure for decoding Huffman codes using leading ones detection |
| EP0619053A1 (en) * | 1991-12-23 | 1994-10-12 | Intel Corporation | Decoder and decoding method for prefixed Huffman codes using plural codebooks |
| CN1098565C (zh) * | 1996-06-07 | 2003-01-08 | 大宇电子株式会社 | 译码变长码的方法和设备 |
| CN1123125C (zh) * | 1997-12-08 | 2003-10-01 | 大宇电子株式会社 | 可变长编码方法及其装置 |
| US6219457B1 (en) * | 1998-05-26 | 2001-04-17 | Silicon Graphics, Inc. | Method and system for decoding data encoded in a variable length code word |
| US6124811A (en) * | 1998-07-02 | 2000-09-26 | Intel Corporation | Real time algorithms and architectures for coding images compressed by DWT-based techniques |
| JP3323175B2 (ja) * | 1999-04-20 | 2002-09-09 | 松下電器産業株式会社 | 符号化装置 |
| EP1069691A1 (en) * | 1999-06-15 | 2001-01-17 | STMicroelectronics S.r.l. | Decoding method for a Huffman code |
| FR2800941A1 (fr) * | 1999-11-09 | 2001-05-11 | France Telecom | Procede de decodage de donnees codees a l'aide d'un code entropique, dispositif de decodage et systeme de transmission correspondants |
| US6411226B1 (en) * | 2001-01-16 | 2002-06-25 | Motorola, Inc. | Huffman decoder with reduced memory size |
-
2001
- 2001-10-19 US US10/045,693 patent/US6563440B1/en not_active Expired - Fee Related
-
2002
- 2002-10-11 EP EP02779788A patent/EP1436899A1/en not_active Withdrawn
- 2002-10-11 CN CNB028198115A patent/CN100477532C/zh not_active Expired - Fee Related
- 2002-10-11 WO PCT/IB2002/004198 patent/WO2003034597A1/en not_active Application Discontinuation
- 2002-10-11 KR KR1020047004806A patent/KR100950607B1/ko not_active IP Right Cessation
Cited By (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101406014B (zh) * | 2006-10-18 | 2012-04-25 | 株式会社石田 | 编码装置、脉冲再现装置和通信系统 |
| CN102237878B (zh) * | 2010-04-20 | 2015-09-02 | 慧荣科技股份有限公司 | 一种霍夫曼解码方法 |
| CN102237878A (zh) * | 2010-04-20 | 2011-11-09 | 慧荣科技股份有限公司 | 一种霍夫曼解码方法 |
| CN104253993A (zh) * | 2013-06-28 | 2014-12-31 | 炬力集成电路设计有限公司 | 一种多媒体数据处理方法、电路及装置 |
| CN104253993B (zh) * | 2013-06-28 | 2018-01-12 | 炬芯（珠海）科技有限公司 | 一种多媒体数据处理方法、电路及装置 |
| CN104283568B (zh) * | 2013-07-12 | 2017-05-17 | 中国科学院声学研究所 | 一种基于部分霍夫曼树的数据压缩编码方法 |
| CN104283568A (zh) * | 2013-07-12 | 2015-01-14 | 中国科学院声学研究所 | 一种基于部分霍夫曼树的数据压缩编码方法 |
| CN106560010A (zh) * | 2014-06-09 | 2017-04-05 | 泰德系统股份有限公司 | Vlsi高效霍夫曼编码设备和方法 |
| CN106560010B (zh) * | 2014-06-09 | 2020-01-03 | 美光科技公司 | Vlsi高效霍夫曼编码设备和方法 |
| CN104717499A (zh) * | 2015-03-31 | 2015-06-17 | 豪威科技(上海)有限公司 | 一种霍夫曼表的存储方法及用于jpeg的霍夫曼解码方法 |
| CN104717499B (zh) * | 2015-03-31 | 2018-06-05 | 豪威科技(上海)有限公司 | 一种霍夫曼表的存储方法及用于jpeg的霍夫曼解码方法 |
| CN113271107A (zh) * | 2020-09-30 | 2021-08-17 | 北京清微智能科技有限公司 | 一种Huffman硬件解码方法 |
| CN113271107B (zh) * | 2020-09-30 | 2024-04-26 | 北京清微智能科技有限公司 | 一种Huffman硬件解码方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2003034597B1 (en) | 2003-07-31 |
| EP1436899A1 (en) | 2004-07-14 |
| KR20040041651A (ko) | 2004-05-17 |
| KR100950607B1 (ko) | 2010-04-01 |
| CN100477532C (zh) | 2009-04-08 |
| WO2003034597A1 (en) | 2003-04-24 |
| US6563440B1 (en) | 2003-05-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1613188A (zh) | 霍夫曼编码 | |
| CN1494767A (zh) | 压缩/解压缩结构化文档的方法 | |
| CN1630202A (zh) | 编码设备、程序和数据处理方法 | |
| CN1177482C (zh) | 编码方法,解码方法,编码装置以及解码装置 | |
| CN1294540C (zh) | 编解码坐标内插符关键字数据和关键值数据的装置 | |
| CN1320769C (zh) | 编码器、解码器以及数据传送系统 | |
| CN1552126A (zh) | 压缩文档的结构化描述的方法和系统 | |
| CN1640142A (zh) | 对小波变换系数进行编码的方法和设备 | |
| CN1099766C (zh) | 数据压缩方法、数据复原方法及信息处理装置 | |
| CN1139191C (zh) | 涡轮码纠错译码方法 | |
| CN101069354A (zh) | 信息压缩编码装置、其解码装置、及其方法和程序以及记录介质 | |
| CN1515078A (zh) | 可变长度编码方法,可变长度译码方法,存储介质,可变长度编码设备,可变长度译码设备,和位流 | |
| CN1528091A (zh) | 压缩层次树的方法、相应的信号以及解码信号的方法 | |
| CN1330455A (zh) | Turbo(涡轮)码的译码电路和编码译码电路 | |
| CN1189019A (zh) | 包括结合多维调制的乘积码的数字传输系统与方法 | |
| CN1226039A (zh) | 指数计算装置和解码装置 | |
| CN1946181A (zh) | 图像处理、压缩、解压缩、传输、发送、接收装置和方法及其程序以及显示装置 | |
| CN1021004C (zh) | 在剩余数系统中用于编码和译码数据的方法和装置 | |
| CN1960336A (zh) | 一种实现灵活QinQ的方法及设备 | |
| CN1269052C (zh) | 支持缩小代码长度的常量还原型处理器 | |
| CN101044687A (zh) | 用于数据压缩优化的方法、系统和计算机程序产品 | |
| CN1848692A (zh) | 编码设备、解码设备、编码方法、解码方法和程序 | |
| CN1390391A (zh) | 并行涡轮编码器实施方案 | |
| CN1649274A (zh) | 可变长度解码装置和可变长度解码方法以及再现系统 | |
| CN1114153C (zh) | 支持程序编码长度减小的微处理器 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| C17 | Cessation of patent right | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20090408 Termination date: 20101011 |