1. 从视频编码到CABAC一个被低估的关键环节CABAC全称是Context-based Adaptive Binary Arithmetic Coding中文通常叫“基于上下文的自适应二进制算术编码”。第一次接触视频编码的人经常被这三个缩写绕晕先是熵编码里的CAVLC然后跳到CABAC中间还夹着各种上下文模型、概率状态、重归一化。我在刚开始看H.264标准的时候对着Table 9-37的那张rangeTabLPS表发了整整两天呆才搞明白这东西到底在干嘛。这其实不怪标准写得复杂而是CABAC本身就是一个把“熵编码”这件事做到极致的模块。它解决的根子问题就一个如何在编码语法元素的时候尽可能少用bit同时还保证解码端能准确还原。在CABAC出现之前H.263、MPEG-4里普遍用的是定长码加简单变长码VLC这类方法有个天然瓶颈——同一个符号在任何位置都用同一张码表概率是固定的。但视频内容千变万化宏块类型、运动矢量、残差系数每个位置的统计特性都不一样。CAVLC虽然做了有限的查表切换但切换粒度仍然比较粗。CABAC不一样它对每个符号都维护独立的概率估计而且概率会随着已编码的内容动态调整所以能把码率压得更狠。这篇是CABAC基础篇目标读者是刚接触视频编码、想在工程或学习中真正搞懂CABAC的同学。我会按自己的理解把CABAC拆成三条线来讲一是语法元素怎么变成二进制bit串二是概率模型怎么选、怎么更新三是算术编码引擎怎么把这些bit串压成最终码流。这三条线走通了后面再去看标准里的状态转移表、range表、初始化表就不会像看天书了。先说一个很多教程忽略的事实CABAC不是一个孤立的算法它依赖前级的结果。前级做完预测、变换、量化之后输出一大串语法元素比如宏块类型mb_type、运动矢量差值MVD、量化系数Level。CABAC的输入是这些语法元素输出是原始码流字节。所以你在编码器代码里会看到CABAC通常放在最后一道工序跟NAL封装挨在一起。初学阶段最容易犯的错误是死磕算术编码那个“区间递推”的数学细节。我的建议是先跳过把整个框架和术语关系理清楚。什么叫上下文什么叫MPS/LPS为什么概率要用查表而不是浮点算这些概念打通了后面看代码的时候会顺很多。2. C第一步把语法元素变成bin串2.1 为什么非要二进制化算术编码可以直接编码多符号但CABAC选择先把所有语法元素映射成一串只含0和1的bin串。直接编码多符号的概率分布比较复杂上下文建模的粒度也粗转成二进制之后每个bit可以单独关联一个概率模型这样概率估计可以做得非常精细。打个比方如果直接编码一个取值范围0到30的整数你面对的是一个31符号的概率分布很难想清楚该用多大表、怎么更新。但把它展开成5个bit之后第一个bit是否置1、第二个bit是否置1往往遵循完全不同的规律。CABAC就可以针对每个bit单独建模灵活性高出不少。H.264标准里二进制化方案一共有五种一元码、截断一元码、截断莱斯码、k阶指数哥伦布码、定长码。不同语法元素根据取值范围和统计特性选不同的方案。整个过程可以概括为两段式映射语法元素值 - bin串 - 算术编码。bin串里的每个元素叫bin每个bin在编码时可能走常规编码引擎也可能走旁路编码引擎。这个概念后面第三节和第五节详细说。2.2 五种二进制化方案的选型逻辑二进制化方案看似多其实选型逻辑很清晰。核心就两个问题这个值有没有上限小值出现的概率是不是显著大于大值。一元码最简单数值n就编码成n个1或0加一个结束位适合小值集中、没有明确上限的场景。但一元码对超大值极不友好n100就要写100个bit所以标准设计了截断一元码给它设了一个上限cMax超过cMax的部分改用定长码或别的方案控制最坏情况下的码长。截断莱斯码是工程里的常用角色它把数值分成商和余数两部分商用截断一元码编余数用定长码编。莱斯参数cRiceParam决定余数用几位码长会根据概率自适应调整。H.264里残差绝对值大于某个阈值后的后缀部分用k阶指数哥伦布UEGk处理这类码对小值高效对稀疏大值也能容忍较长码字。定长码就没什么可讲的直接用log2(cMax1)个bit表示用于均匀分布或小范围枚举型语法元素。2.3 拿一个真实语法元素串一遍以残差系数绝对值为例。H.264里对coeff_abs_level_minus1先用一个cMax14的截断一元码做前缀如果值大于等于14再用0阶指数哥伦布做后缀。这样做的好处是绝大多数系数绝对值都集中在0到13之间前缀部分就能覆盖只有少数大系数才需要进后缀避免了全表定长码的浪费。这里有个初学者容易迷糊的地方二进制化不一定要跟概率模型一一对应。同一个语法元素拆出来的bin可能前几个bin各配各的上下文后面的bin共享一个上下文具体怎么分标准里都有明确的ctxIdx映射。真正决定压缩率上限的不是二进制化本身而是后面这些bin怎么通过上下文模型分配概率。3. 上下文建模CABAC智能的关键3.1 上下文到底是什么“上下文模型”这个名字听起来抽象其实就是一个“按条件分组使用的概率估计器”。CABAC里每个bin都对应一个上下文索引ctxIdx每个ctxIdx维护两个量当前LPS低概率符号的概率状态pStateIdx以及MPS高概率符号的值MPS是0还是1。为什么需要分这么多上下文因为视频编码里的符号概率高度依赖周围信息。比如当前宏块是否跳过跟左侧和上方宏块是否跳过高度相关。如果不管周围情况统一用一个概率估计你用50%去猜一个实际90%会发生的符号码率自然低不下来。CABAC的做法是对同一类语法元素在不同相邻条件下使用不同的上下文模型。比如H.264里skip_flag的上下文选择会参考左侧宏块和上方宏块的skip状态一共可能对应三个不同ctxIdx。上下文建模的粒度直接影响压缩性能和复杂度。上下文越多模型越精准但概率表的存储会变大编码前端的上下文选择逻辑也更复杂而且WPP并行时上下文会在slice边界重置这也是并行效率的潜在瓶颈。3.2 概率状态机的转移规律CABAC不使用浮点数更新概率而是用查表加状态跳转。标准把LPS概率划分成64个离散状态pStateIdx从0到63每个状态对应一个LPS概率值。概率变化不是在数学上算出来的而是编码一个bin之后按照标准定义的两个转移数组跳一下当前bin等于MPS时pStateIdx按转移数组MPS方向变化概率向“更可能”方向修正当前bin等于LPS时pStateIdx按转移数组LPS方向变化概率向“更不可能”方向修正如果pStateIdx已经到0也就是说LPS概率已经相当低此时再出现LPS说明概率预测反了MPS翻转。这个机制是CABAC自适应能力的核心。编了一段数据之后模型会自动收敛到接近真实分布的状态不需要编码器额外传概率信息解码端也能通过同样的规则同步更新。3.3 概率初始化与QP的联动上下文模型的初始状态不是随便拍的。标准为每个上下文都准备了一组初始化参数m和n然后根据当前条带的sliceQP计算初始状态。大体公式就是m乘sliceQP右移4位再加n再把这个数值映射到64个概率状态和MPS方向。这样做有一个很实际的考虑量化参数大的时候残差系数普遍偏小某些上下文比如大系数标志初始概率应该偏向“不出现”。如果不跟QP联动编码器在低码率、高QP场景下要花很多个bin才能把模型拉到合理概率区等于白白浪费码字。工程实现中每个slice类型I/P/B都有自己的一组m、n表。实际代码里不会每次都做乘加运算通常是把初始化结果预先算好存成一张表slice开始的时候直接拷贝到上下文状态数组里。在我自己实现的编码器里这个初始化表大概占几KB相对整个模块开销很小但换来的性能确定性很值得。4. 二进制算术编码引擎从区间递推到重归一化4.1 区间递推的直观理解算术编码的数学底子是无限精细的概率区间划分。我自己的理解方式是把它想成在一条长度不断缩小的绳子上做标记每编码一个符号就把当前绳子的一个子段保留下来另一个子段丢弃。最终保存的不是具体区间值而是区间内任何一个点的二进制表示解码端用相同的分割规则就能复原。CABAC用的是整数算术编码编码一个bin时需要维护两个量当前区间长度R以及区间下界low。编码流程可以概括为用R的高两位查表得到当前bin的LPS子区间长度R_LPS如果待编码bin等于MPS区间收缩到R - R_LPSlow保持不变如果待编码bin等于LPS区间收缩到R_LPSlow加上R - R_LPS收缩后如果R小于256做重归一化也就是不断左移直到R回到合法范围。整个过程只涉及整数加法和移位没有乘法除法这是CABAC能在软硬件里高效跑起来的关键。4.2 重归一化与比特输出重归一化不只是把区间放大它还要把区间变化反映到输出码流里。实际工程里low寄存器通常会多保留几位比如9位当low小于256时输出0大于等于512时输出1并减256落在中间时不立刻输出而是记录一个“悬置进位”的计数器等待下一个确定位再决定进位怎么传播。常见实现里有一段这样的伪代码while (R 256) { if (low 256) { put_bit(0); } else if (low 512) { put_bit(1); low - 256; } else { bits_outstanding; low - 256; } low 1; R 1; }这里最容易出错的是bits_outstanding的处理。如果后续出现进位之前悬置的那些bit都要翻转为另外一个值。很多刚写CABAC的开发者会在这里栽跟头输出的码流里出现丢bit或者多bit。排查的时候最好的办法是跑一个已知码流的对照测试对比每一帧的字节输出。4.3 常规模式与旁路模式CABAC里不是所有bin都走上下文模型。有些bin概率接近均匀分布比如运动矢量差值符号位这类bin如果硬套上下文不仅压不动还浪费几百个上下文状态。所以标准设计了旁路bypass模式假设概率始终是0.5不做任何状态更新直接把区间等分为两半再编码。旁路模式的好处是概率固定为0.5不需要查表不需要做条件和转移可以按固定步长做区间更新和输出。很多工程的CABAC硬件加速器会把旁路编码做成一个单独的高速处理通道吞吐率比常规模式高不少。旁路模式和常规模式在一个bin串里是穿插出现的。标准会在每个语法元素的二进制化结果上标明每个bin走常规还是旁路。编写编码器的时候不能只按“语法元素”为单位抽象而要以“bin”为单位因为同一个语法元素的bin可能前半段走常规、后半段走旁路H.264里的MVD、coeff_abs_level_minus1都有这种情况。5. 工程实现中的注意事项与优化思路5.1 串行依赖与并行编码CABAC是强串行结构因为每个bin编码之后都会改变概率状态和区间状态下一个bin必须依赖当前状态。这对并行不友好。在实际工程里最常见的应对手段是分slice并行每个slice分配一段独立的CABAC流slice之间互不影响。H.264/H.265里还有WPPWavefront Parallel Processing它利用宏块行与行之间的延迟启动让不同线程处理不同宏块行但每一行的进度错开一个宏块保证上下文依赖是完整的。我在做多线程编码的时候WPP带来的线程同步复杂度比想象中高很多建议初期先用slice并行稳定之后再上WPP。5.2 上下文状态同步是调试的重灾区编码器和解码器对上下文状态的更新规则必须完全一致否则解码端从某一个bin开始概率错乱整个slice都救不回来。我踩过的一个坑是编码端在跳过某些语法元素比如PCM模式时忘了更新对应的上下文状态解码端却照常更新结果码流解码到后续宏块全部花屏。排查这种问题没有捷径就是逐bin比对编码解码两端的ctxIdx和状态变化写一个debug工具记录每个bin的上下文跳转轨迹。另一个我反复提醒自己的点上下文数量不是越多越好但编号映射千万不能省。标准里每个语法元素用了哪些ctxIdx、映射到哪一段都有明确表格。工程上建议直接按标准顺序线性排列上下文并加一段越界断言编码器调试期跑一次全测试序列能把大部分映射错误暴露出来。5.3 查表优化与定点精度控制CAVLC时代码表长度不过几十项查表几乎不需要担心性能。CABAC的rangeTabLPS表是64×4每项8bit很小但它会被高频调用。我在软编码器里会把上下文状态和range查表拆成不依赖分支的函数直接用乘法做状态索引预计算避免每次编码一个bin都产生缓存miss。需要特别注意的是CABAC必须全程定点点计算不允许引入浮点。不同平台浮点舍入不一致会导致编解码结果不同。只要有一次运算路径上的状态差1输出码流就可能无法被另一端的解码器解析。有一个老生常谈但非常好用的调试手段旁路模式统测。把所有bin都切到旁路模式此时CABAC退化成近似的均匀算术编码编解码链路简单很多。先把旁路模式下码流能通再逐个打开常规上下文逐步逼近完整功能。我做RTL验证时也采用这个策略定位问题速度能快不少。5.4 关于位填充和码流封装CABAC输出的是一个无限长二进制小数实际写入NAL单元时会做位填充bit stuffing来防止出现start code仿真。H.264 ANEX B格式里每输出一个0x000001前缀的前缀模式就要插入一个防止竞争的0x03字节。编码器需要维护一个字节级别的输出缓冲在写入原始字节之后统一做启动码仿真检查而不是每次write都扫描整个NAL否则大分辨率编码时的性能损耗很明显。这里还有一个容易造成困惑的点CABAC的末尾字节未必对齐。编码完成后必须用encode_terminate的方式送一个终止bin然后调用flush把剩余区间和悬置位全部输出并且对齐到字节。如果不做这个操作解码端读取时会缺少结尾判定容易把下一帧的开头数据误读进来。6. 常见问题速查与排障清单我在实际落地CABAC的过程中遇到过不少值得记录的问题整理成一张表方便后面排查。现象可能原因处理思路码流能解码但PSNR比预期低很多上下文模型选择错用了不相邻的块信息对照标准里的ctxIdx映射逐项核查解码到某个宏块后花屏编码端或解码端有一侧未更新上下文状态逐bin打印状态锁定第一个失同步bin输出字节里出现连续FF且进位错误bits_outstanding悬置位的进位处理写错检查重归一化分支对照JM/x264实现旁路模式正常常规模式崩溃rangeTabLPS查表索引的R前导位提取错误重点检查q (R 6) 3这步的位宽slice末尾多出或丢失字节没做encode_terminate和flush补充终止bin和字节对齐逻辑大QP序列比CAVLC还差上下文初始化没跟随QP检查m、n初始化公式和slice类型这些问题的共性原因都指向一件事CABAC里每一步都强依赖于前一步的结果任何一处状态偏差都会往后积累放大。所以排障的时候不要想着“目测代码”可行的方法就是加详细状态日志对照标准参考软件的中间状态一步一步逼近。以我个人的实际体会CABAC的难度不在于算法本身的数学复杂度而在于状态同步的细节实在太多。如果你自己动手写一个软编码器建议先不做任何优化只求功能和正确性用标准测试序列跑通所有帧类型再去考虑查表加速、流水线、WPP这些工程优化。基础篇先讲到这里后面有机会我把H.264里每个语法元素的具体ctxIdx分配和初始化表拆开讲那个部分更细碎也更考验耐心。