24. 媒体编解码器扩展：自定义编解码器、Vendor扩展接口、Codec2.0过渡

各位同学，今天我们来聊聊编解码器的扩展能力。说实话，这部分内容在平时开发中可能不太常用，但一旦遇到定制需求，它就是你的救命稻草。我自己在几个项目中都踩过这里的坑，今天一并分享给你们。

24.1 为什么需要编解码器扩展？

Android的媒体框架，说白了就是一套标准化的流水线。但现实世界里的硬件千奇百怪，芯片厂商总有自己的一套优化方案。比如某家厂商的VPU支持硬件加速的H.265 10bit编码，但Google原生框架里根本没这配置。怎么办？

这时候就需要扩展机制了。我当年在做一个视频监控项目时，客户要求支持自定义的私有编码格式，原生Codec列表里压根没有。嗯，那会儿我硬着头皮研究了整整两周的Vendor扩展接口。

24.2 自定义编解码器的实现路径

自定义编解码器，通常有两种玩法：

• 完全自研：从零写一个OMX组件或C2组件，注册到系统中
• 封装现有库：把FFmpeg、x264等开源库包装成Android可识别的组件

我个人更推荐第二种，毕竟重复造轮子不是好习惯。来看一个简单的封装思路：

// 自定义OMX组件的基本骨架
class MyCustomCodec : public android::SoftOMXComponent {
public:
    MyCustomCodec(const char *name,
                  const OMX_CALLBACKTYPE *callbacks,
                  OMX_PTR appData,
                  OMX_COMPONENTTYPE **component)
        : SoftOMXComponent(name, callbacks, appData, component) {
        // 初始化你的编码器库
        mEncoder = new MyPrivateEncoder();
    }

protected:
    virtual void onQueueFilled(const sp<MediaBuffer> *buffers, size_t count) {
        // 从输入buffer读取原始数据
        // 调用私有编码器处理
        // 输出编码后的数据到output buffer
        for (size_t i = 0; i < count; i++) {
            mEncoder->encode(buffers[i]->data(), outputData, &outputSize);
            // 填充输出
        }
    }

private:
    MyPrivateEncoder *mEncoder;
};

这段代码看起来简单，但实际坑不少。我曾经在onQueueFilled里忘记处理EOS标志，结果导致编码器在最后一帧卡死——整整排查了两天。

24.3 Vendor扩展接口详解

Vendor扩展接口，说白了就是芯片厂商在标准OMX IL之上加的私货。每个厂商都有自己的套路：

厂商	扩展接口名称	典型用途
Qualcomm	QOMX_EXTN_*	硬件编码参数调优、低功耗模式
MediaTek	MTK_OMX_*	画质增强、HDR元数据传递
Rockchip	RK_OMX_*	多路编码同步、ROI区域设置

这些扩展接口怎么用？其实就是在标准OMX_SetParameter时传入厂商自定义的index。举个例子：

// 设置高通平台的编码器低延迟模式
OMX_INDEXTYPE index;
OMX_STRING paramName = "QOMX_EXTN_VIDEO_ENCODER_LOW_LATENCY";

OMX_GetExtensionIndex(mOMXComponent, paramName, &index);

OMX_BOOL enableLowLatency = OMX_TRUE;
OMX_SetParameter(mOMXComponent, index, &enableLowLatency);

这里有个坑：不同厂商的扩展参数名可能冲突。我记得有一次在MTK平台上误用了高通的扩展参数，结果OMX_GetExtensionIndex返回了错误，但没报任何异常——编码出来的视频全是花屏。

24.4 Codec2.0过渡：从OMX到C2

Codec2.0，简称C2，是Google用来取代OMX IL的新框架。为什么要换？OMX IL太老了，设计上有很多历史包袱：

• OMX IL是C语言接口，没有类型安全
• 状态机复杂，容易死锁
• Buffer管理混乱，内存泄漏频发

C2的设计思路就清爽多了。它用C++接口，引入了组件图的概念。来看一个C2组件的基本结构：

// Codec2.0组件示例
class MyC2Component : public C2Component {
public:
    MyC2Component(const C2String &name)
        : C2Component(name) {
        // 注册支持的输入输出格式
        addParameter(
            C2StreamFormatInfoInput::make(0, 0, C2FormatVideo));
        addParameter(
            C2StreamFormatInfoOutput::make(0, 0, C2FormatCompressed));
    }

    c2_status_t start() override {
        // 初始化编码器硬件
        return C2_OK;
    }

    c2_status_t stop() override {
        // 释放资源
        return C2_OK;
    }

    c2_status_t queueBuffer(
        const std::shared_ptr<C2Buffer> &buffer) override {
        // 处理输入buffer
        return C2_OK;
    }
};

你可能会问：那OMX组件还能用吗？答案是：能，但Google在逐步淘汰它。从Android 10开始，新设备必须支持C2。但OMX组件可以通过一个兼容层跑在C2框架上。

我个人建议：新项目直接上C2。虽然OMX的文档更丰富，但C2的设计更合理，调试起来也方便。我去年把一个OMX的H.264编码器迁移到C2，代码量减少了30%，性能还提升了5%。

24.5 核心知识体系

下面这张图是我自己整理的编解码器扩展知识体系，你们可以对照着理解：

24.6 避坑指南与最佳实践

最后，我把自己这些年踩过的坑总结一下：

1. 不要迷信Vendor扩展：厂商的扩展接口通常没有完整文档，而且不同版本可能不兼容。我曾经在QCOM平台上用了一个扩展参数，结果驱动升级后直接失效。
2. 做好降级策略：自定义编解码器如果初始化失败，要能优雅地回退到软件编码。别让整个播放流程卡死。
3. 测试要覆盖多设备：同一个厂商的不同芯片，对扩展接口的支持程度可能完全不同。我建议至少测试3-5款主流设备。
4. C2迁移要趁早：虽然OMX还能用，但Google已经在Android 14中移除了部分OMX调试工具。早点迁移，后面省心。

好了，关于编解码器扩展的内容就讲到这里。这部分知识比较底层，但理解了它，你就能真正掌控Android的多媒体能力。下次遇到定制需求，别慌，按我们今天讲的思路来就行。

---

公众号:蓝海资料掘金营，微信deep3321