为何H.265（HEVC）中Golomb编码占比特更多却仍被采用？

问题背景 #

我在解析HEVC（H.265）头部时，发现诸多值采用Golomb编码表示，例如宽度值。假设宽度为1600，其Golomb编码为：

g=000000000001001000001

将编码字符串左侧连续的部分称为"leadingZero"（lz），此处lz为11个0；剩余部分称为b。
解码时，b=1001000001（十进制为577），计算公式为：

a=2^(lz-1)-1;
n=a+to_decimal(b)

其中to_decimal用于将二进制转换为十进制，计算得1023+577=1600。

疑问：用Golomb编码表示1600需21比特，而1600的二进制仅需11比特（110 0100 0000），且Golomb编码无法自定义比特数。那么为何H.265这类压缩算法仍采用Golomb编码？

解答 #

Golomb编码的价值从来不是给单个大数值节省比特，而是针对偏态概率分布的数据实现全局最优压缩，这也是熵编码的核心目标：

• 适配HEVC数据的概率特征：HEVC中绝大多数待编码的语法元素（比如预测残差、模式选择索引、运动向量差值等）都是小数值占比极高，大数值极少出现。比如运动向量差值，多数时候是0或±1这类极小值，大差值的情况寥寥无几。Golomb编码对小数值的编码效率极高：比如数值0仅需1比特，数值1可能只需要2-3比特，远优于固定长度的二进制编码。
• 全局比特开销更优：像宽度这种偶尔出现的大数值，虽然用Golomb编码会多占比特，但从整个视频流的全局来看，大量小数值节省的比特量完全能覆盖少数大数值的额外开销，最终整体编码的平均比特率更低。
• 自适应无参数特性：HEVC实际使用的是指数哥伦布编码（Golomb的变种），它不需要预先传递编码参数（比如固定比特长度），解码器可以直接从码流中解析出编码规则，能自适应不同场景下的数据分布变化，既灵活又不会增加额外的参数传输开销。

简言之，熵编码追求的是全局平均比特率最低，而非单个数值的比特数最少。Golomb编码正是为“小值高频、大值低频”的典型分布量身打造的，这也是它在HEVC等视频压缩标准中被广泛采用的核心原因。

内容的提问来源于stack exchange，提问作者Massimo