【发布时间】:2011-12-25 10:53:48
【问题描述】:
第一次用这个网站问一个问题,但我得到了很多很多答案!
背景:
我正在解码使用 RLE 和 Huffman 编码进行编码的可变长度视频流。流的长度为 10 到 20 KB,因此我试图从每一步中“挤出”尽可能多的时间,以便可以实时有效地对其进行解码。
现在我正在处理的步骤涉及将比特流转换为基于 Huffman 表的数字。我通过计算前导零的数量来确定要包含的尾随位的数量来做到这一点。表格如下:
001xs range -3 to 3
0001xxs range -7 to 7
00001xxxs range -15 to 15
一直到 127。s 是符号位,0 表示正数,1 表示负数。因此,例如,如果 clz=2,那么我将读取接下来的 3 位,2 位表示值,1 位表示符号。
问题:
现在我为此创建的讨厌的表达是:
int outblock[64];
unsigned int value;
//example value 7 -> 111 (xxs) which translates to -3
value=7;
outblock[index]=(((value&1)?-1:1)*(value>>1)); //expression
有没有更简单快捷的方法来做到这一点?
感谢您的帮助!
提姆
编辑:表达式已编辑,因为它没有生成正确的正值。现在正确生成正负。
【问题讨论】:
-
我不明白你为什么要计算前导零的数量,那些零代表什么?接下来,您发布的代码 sn-p 是执行流的 Huffman 解码,还是仅构建您稍后在实际解码期间使用的表?
-
零确定要读取的值的尾随位数。
-
零表示要读取的值的尾随位数。代码 sn-p 显示了我用于将从流中读取的位转换为输出值的当前表达式。在示例中,如果您有 2 个前导零,那么您需要读取接下来的 3 位。接下来的 3 位是 111 -> 7。这是您输入表达式的值,它产生 -3(11 -> 3 和 1 表示负号)。我从来没有真正生成过表格。我只是好奇是否有办法“优化”我创建的这个表达式,因为我必须每 10 毫秒使用这个表达式大约 2000 次。
-
这是什么编解码器?至少,这不是您在 JPEG 中使用的那种霍夫曼编码。它类似于“附加位”的计算。在 JPEG 中,霍夫曼代码决定了编码系数需要多少额外的位。如果前导位为零,则该值直接从二进制表示转换而来,其长度由霍夫曼代码确定。否则你减去 (2^length)-1。
-
它是 Huffman 和 RLE 编码的变体。在此编码步骤之前,图像都遵循 JPEG 规范。
标签: c performance huffman-code