引言：那些"神秘"的 vendor 参数是怎么来的用MediaCodec开发的时候，偶尔会看到这样的代码：format.setInteger("vendor.qti-ext-enc-ltr-count.num-ltr-frames",4);format.setInteger("vendor.rtc-ext-enc-low-latency.enable",1);这些以vendor.开头的参数是什么？为什么官方文档里找不到？它们是怎么传递到硬件编码器的？答案在OMX和Codec2这两个框架里。它们是MediaCodec和硬件之间的"翻译层"，也是整个 Android 编解码架构最复杂、最厂商定制化的部分。理解了这一层，你才能真正读懂 Vendor 的编解码优化文档，才能在不同芯片平台上榨出最优性能，才能处理那些"换了手机就出问题"的兼容性 Bug。一、两代框架的历史背景1.1 OMX（OpenMAX IL）：第一代OMX 全称OpenMAX Integration Layer，是 Khronos Group 制定的多媒体组件标准（类似 OpenGL 之于图形）。Android 从 2.0 开始基于 OMX 构建编解码框架，核心实现是ACodec（libstagefright）。OMX 的基本单元是组件（Component），每个编解码器是一个组件，通过 Port 端口传递 Buffer。问题在于：OMX IL 规范设计于 2006 年，面向嵌入式设备，用 C 接口、全局状态、阻塞调用——在 2016 年多核 SoC 的时代显得捉襟见肘。1.2 Codec2：第二代（Android 10+）Google 从 Android 9 开始引入 Codec2（内部代号 C2），Android 10 开始强制要求新设备支持。Codec2 彻底重写了 Framework 侧逻辑，用C++17 模板类替代了 OMX 的 C 接口，引入了现代化的内存模型（C2Buffer/C2Block）和异步工作流（C2Work）。为什么叫 Codec2 而不是 Codec v2？因为第一版直接叫"codec"（OMX），第二版就叫 Codec2，表示这是彻底的重新设计，而非小修小补。二、OMX 框架深入：ACodec 工作原理2.1 ACodec 状态机ACodec是MediaCodec在 OMX 通道上的具体实现，也是一个状态机：Uninitialized │ allocateComponent() ▼ Loaded │ configureComponent() + allocateBuffers() ▼ Idle │ executeComponent()（OMX_CommandStateSet → Executing） ▼ Executing ← 正常运行状态，通过 OMX_EmptyThisBuffer / OMX_FillThisBuffer 传递 Buffer │ │ OMX_EventPortSettingsChanged（分辨率变化时） │ → 临时进入 OutputPortSettingsChangedState │ → 重新分配 Output Buffer │ → 回到 Executing │ │ flush() → OMX_CommandFlush │ stop() → OMX_CommandStateSet Idle → Loaded2.2 OMX Buffer 传递OMX 的 Buffer 传递是所有权转移语义：Framework（ACodec） OMX Component（硬件驱动） │ │ OMX_UseBuffer()：告知 HAL 使用 Framework 分配的 Buffer 地址 │ ──────────────────────────────────────────────────────────► │ Buffer 所有权在 HAL │ OMX_EmptyThisBuffer(inputBuffer)：把输入 Buffer 填好后交给 HAL │ ──────────────────────────────────────────────────────────► │ HAL 处理后回调 │ ◄──────────────────────────────────── EmptyBufferDone() │ Buffer 所有权回到 Framework │ │ OMX_FillThisBuffer(outputBuffer)：把空的输出 Buffer 交给 HAL 填 │ ──────────────────────────────────────────────────────────► │ HAL 填完后回调 │ ◄──────────────────────────────────── FillBufferDone() │ 拿到填好的 BufferOMX 的设计缺陷：Buffer 在 Framework 和 HAL 之间频繁"交接"，每次所有权转移需要两次函数调用。加上 OMX 接口是同步的（OMX_SetParameter会阻塞直到 HAL 响应），在高帧率场景下延迟和开销都很明显。2.3 OMX 扩展参数：vendor.xxxOMX 规范定义了标准参数（OMX_IndexParamVideoAvc等），但厂商需要暴露更多硬件能力，于是引入了Vendor Extension：// 高通在 OMX HAL 中注册扩展参数constchar*extParam="OMX.QTI.index.param.video.LTRCount";OMX_INDEXTYPE ltrIndex;OMX_GetExtensionIndex(hComp,extParam,ltrIndex);OMX_SetParameter(hComp,ltrIndex,ltrStruct);这些扩展参数通过一个映射表暴露到MediaFormat，就是我们看到的vendor.qti-ext-enc-ltr-count.num-ltr-frames。Codec2 中有更规范的 Vendor Parameter 机制（见后文）。三、Codec2 框架深入：C2Component 接口3.1 C2Component 核心接口Codec2 的组件接口比 OMX 简洁得多，核心只有三个操作：// C2Component 接口（简化）classC2Component{public:// 提交工作单元（输入 + 输出 Buffer 描述）virtualc2_status_tqueue_nb(std::liststd::unique_ptrC2Work*constitems)=0;// 刷新：丢弃所有待处理的工作，返回未完成的工作virtualc2_status_tflush_sm(flush_mode_t mode,std::liststd::unique_ptrC2Work*constflushedWork)=0;// 向组件发送 drain（结束符），请求输出所有缓存的帧virtualc2_status_tdrain_nb(drain_mode_t mode)=0;// 状态控制virtualc2_status_tstart()=0;virtualc2_status_tstop()=0;virtualc2_status_trelease()=0;};3.2 C2Work：工作单元Codec2 的核心抽象是C2Work，每个工作单元包含一组输入 Buffer + 输出 Buffer 描述，以及 metadata：structC2Work{// 输入：一个或多个 C2FrameDatastd::liststd::unique_ptrC2StreamBufferinput;// 压缩码流 Buffer// 处理链（通常只有一个节点）std::vectorstd::unique_ptrC2Workletworklets;// 完成后的结果（异步回调时由 Component 填充）// worklets[0].output 包含解码/编码后的 C2Buffer};structC2Worklet{C2FrameData output;// 输出 Buffer（解码帧/编码码流）c2_status_t result;};3.3 C2Buffer 内存模型C2Buffer 是 Codec2 最重要的改进之一。它基于引用计数 + 共享内存，解决了 OMX 的所有权混乱问题：// C2Buffer 的两种底层类型：// 1. C2LinearBlock：线性内存（压缩码流、音频 PCM）std::shared_ptrC2LinearBlockblock;C2BlockPool::local_id_t poolId=C2BlockPool::BASIC_LINEAR;blockPool-fetchLinearBlock(capacity,{C2MemoryUsage::CPU_READ,C2MemoryUsage::CPU_WRITE},block);// 写入数据C2WriteView wv=block-map().get();memcpy(wv.data(),srcData,size);// 创建 C2Buffer（只读视图，可以跨线程/进程共享）std::shared_ptrC2Bufferbuffer=C2Buffer::CreateLinearBuffer(block-share(offset,size,C2Fence()));// 2. C2GraphicBlock：图形内存（YUV 帧，GPU 可访问）std::shared_ptrC2GraphicBlockgraphicBlock;blockPool-fetchGraphicBlock(width,height,HAL_PIXEL_FORMAT_YCbCr_420_888,{C2MemoryUsage::CPU_READ,C2MemoryUsage::HW_CODEC_WRITE},graphicBlock);C2Fence：异步同步机制C2Buffer 配套 C2Fence，功能类似 Android sync fence，但集成在 Codec2 框架内：// 等待 fence 信号后才能访问 BufferC2Fence fence=buffer-fence();if(fence.valid()){c2_status_t err=fence.wait(timeoutNs);// err == C2_OK：Buffer 已准备好// err == C2_TIMED_OUT：超时}3.4 C2ComponentStore：组件注册Codec2 通过C2ComponentStore管理所有可用的编解码器。系统启动时，MediaCodec Service 会加载所有已注册的 Store：// 获取所有已注册的 C2ComponentStore（代码路径：libmediacodec2）std::vectorstd::shared_ptr