编码器硬件架构：核心计算单元与数据流
编码器硬件，说白了就是一堆专用电路在拼命算。我刚开始接触高通平台时，总觉得软件编码调调参数就行，直到被功耗和延迟教做人——硬件编码器的架构设计，直接决定了你能不能在手机这种功耗受限的设备上跑出1080p@60fps。
这一章我们拆开来看，编码器里到底有哪些关键模块，它们各自在干什么，又是怎么配合的。
2.1 核心计算单元：ME/MC/DCT/QP
这四个模块是编码器的体力活担当。我习惯把它们分成两组：运动估计/运动补偿（ME/MC）负责时域压缩，DCT/QP负责频域压缩。
2.1.1 运动估计（ME）与运动补偿（MC）
ME是整个编码器里最耗计算资源的模块，没有之一。它的任务很简单：在当前帧里找一个块，去参考帧里找最像它的块，然后算出位移向量。
关键指标：
- 搜索范围：±64 ~ ±128 像素（1080p典型值）
- 块大小：16x16（宏块）或 4x4 ~ 64x64（HEVC）
- 匹配准则：SAD（差和）或 SATD（哈达玛变换后差和）
我在一个4K项目里遇到过ME搜索范围设太大，导致每帧处理时间翻倍的情况。后来把搜索范围从±256砍到±96，画质几乎没变，功耗降了30%。
MC就相对轻量了——它根据ME算出的运动向量，从参考帧里把对应块搬过来，生成预测帧。说白了就是查表+插值。
2.1.2 DCT与量化（QP）
DCT把空间域的像素值转换到频率域。低频分量集中在左上角，高频分量在右下角。人眼对高频不敏感，所以量化阶段可以狠一点。
QP（量化参数）控制压缩比和画质的平衡。QP越大，高频系数被砍得越狠，码率越低，但块效应越明显。
| QP值 | 压缩比 | 画质 | 典型场景 |
|---|---|---|---|
| 0~12 | 低 | 无损/近无损 | 医疗影像、存档 |
| 20~28 | 中 | 高 | 视频会议、直播 |
| 32~40 | 高 | 中等 | 短视频、监控 |
| 45~51 | 极高 | 差 | 缩略图、极低码率 |
注意：高通平台硬件编码器的QP值通常有硬件限制范围。比如某些芯片的HEVC编码器QP只能设0~51，但实际硬件支持的步长可能只有整数。我曾经踩过坑——设了QP=22.5，结果硬件直接截断成22，码率控制全乱套。
2.2 码率控制逻辑
码率控制是编码器的“大脑”。它决定每一帧、每一个宏块该用多少比特。高通硬件编码器通常支持三种模式：CBR（恒定码率）、VBR（可变码率）、CQP（恒定QP）。
2.2.1 三种模式对比
| 模式 | 特点 | 适用场景 | 功耗影响 |
|---|---|---|---|
| CBR | 码率严格恒定，缓冲区满时强制跳帧 | 直播、视频通话 | 中等 |
| VBR | 码率波动，画质优先 | 本地录制、点播 | 较高 |
| CQP | 固定QP，码率不可控 | 调试、测试 | 最低 |
我个人习惯在移动端优先用VBR。CBR虽然码率稳，但遇到复杂场景容易跳帧，用户体验很差。VBR配合一个合理的最大码率上限，既能保证画质，又不会撑爆带宽。
2.2.2 码率控制的核心参数
- 目标码率（Target Bitrate）： 单位kbps，决定平均压缩比
- 最大码率（Max Bitrate）： 防止突发流量撑爆缓冲区
- 缓冲区大小（Buffer Size）： 单位ms或bits，控制码率波动幅度
- 初始QP（Initial QP）： 编码开始时的QP值，影响前几帧画质
经验之谈：高通平台的码率控制逻辑在场景切换时反应偏慢。我建议在检测到场景切换时，手动重置码率控制状态，否则前5~10帧会出现明显的画质波动。
2.3 参考帧管理
参考帧是编码器的“短期记忆”。H.264最多支持16个参考帧，HEVC可以更多。但参考帧越多，内存占用和带宽消耗就越大。
2.3.1 参考帧列表结构
编码器维护两个列表：List0（前向参考）和List1（后向参考）。P帧只用List0，B帧两个都用。
// 参考帧管理伪代码
struct RefFrameList {
int num_ref_frames; // 参考帧数量
int max_ref_frames; // 最大参考帧数（硬件限制）
frame_t* list0[MAX_REFS]; // 前向参考帧指针数组
frame_t* list1[MAX_REFS]; // 后向参考帧指针数组
int poc_order[MAX_REFS]; // 按POC排序的索引
};
// 更新参考帧列表
void update_ref_list(RefFrameList* rfl, frame_t* current_frame) {
// 滑动窗口：移除最旧的参考帧
// 插入当前帧（解码完成后）
// 按POC重新排序
}2.3.2 参考帧管理的功耗优化
参考帧管理直接影响DDR带宽。每多一个参考帧，ME就要多读一帧的数据。我建议：
- 低功耗场景：只用1~2个参考帧
- 高质量场景：最多4个参考帧
- 超过4个参考帧，画质收益微乎其微，功耗却线性增长
避坑指南：我曾经在一个项目里把参考帧数设成8，结果编码器频繁触发带宽瓶颈，帧率直接从60fps掉到30fps。后来发现高通某款芯片的硬件ME引擎一次最多只能读4个参考帧，超过的部分要排队等DDR带宽——白白浪费周期。
2.4 熵编码器：CABAC与CAVLC
熵编码是编码器的最后一步，把量化后的系数和语法元素压缩成二进制码流。高通硬件编码器支持两种模式：CAVLC（上下文自适应可变长编码）和CABAC（上下文自适应二进制算术编码）。
2.4.1 两种模式对比
| 特性 | CAVLC | CABAC |
|---|---|---|
| 压缩率 | 较低（比CABAC高5~15%码率） | 较高 |
| 计算复杂度 | 低 | 高（约2~3倍） |
| 硬件面积 | 小 | 大 |
| 功耗 | 低 | 高 |
| 适用场景 | 低功耗、低延迟 | 高质量、高压缩比 |
说白了，CABAC用更复杂的计算换更小的码流。高通平台默认用CABAC，但如果你对功耗敏感，可以切到CAVLC。
2.4.2 CABAC的硬件实现要点
CABAC的核心是概率状态机。每个语法元素都有一个上下文模型，记录它出现0或1的概率。硬件实现时要注意：
- 上下文模型数量： H.264有460个，HEVC有154个。每个模型需要存储概率状态和MPS（最可能符号）
- 二进制算术编码器： 用查表法实现区间划分，避免浮点运算
- 码流打包： 每次编码输出1~8位，需要位对齐和字节填充
性能数据：高通骁龙8 Gen2的硬件CABAC引擎，在4K@60fps场景下，典型功耗约15~25mW。如果切到CAVLC，可以降到8~12mW，但码率会增加约10%。
2.5 整体架构图
下面这张图展示了编码器内部的核心数据流。我习惯把它画成流水线形式——每个模块都在并行工作，但数据依赖关系决定了它们必须按顺序执行。
这张图里我特意加了码率控制的反馈路径——它从量化阶段读取实际产生的比特数，然后调整后续帧的QP。这个闭环控制做得不好，码率就会像过山车一样忽高忽低。
2.6 本章小结
编码器硬件架构的核心就这四块：ME/MC做运动补偿，DCT/QP做频域压缩，码率控制做全局调度，熵编码做最后的码流打包。每个模块都有功耗和性能的权衡点。