20、多媒体框架：MediaCodec、Stagefright、硬件编解码
多媒体这块，说实在的，是嵌入式Android开发里最让人头疼的部分之一。你想想看，一个视频从文件到屏幕上显示出来，中间要经过多少道工序？解封装、解码、渲染、同步……哪一步出问题，画面就卡住或者花掉。
我个人习惯把多媒体框架比作一条流水线。今天我们就来拆开这条流水线，看看里面最核心的几个部件：MediaCodec、Stagefright，还有硬件编解码到底是怎么回事。
核心要点：多媒体框架的本质，就是协调CPU和硬件加速单元，高效地完成音视频数据的处理与流转。
20.1 从Stagefright说起
Stagefright是Android从2.3开始引入的多媒体播放框架。它取代了早期的OpenCore，成为Android多媒体子系统的核心。嗯，这里要注意，Stagefright并不是一个单独的库，而是一整套架构，包括媒体解析器、解码器、渲染器等等。
我在项目中遇到过一个问题：某个MP4文件在手机上播放正常，但在我们的嵌入式设备上就是打不开。后来排查发现，是Stagefright框架里的解析器对某些MP4的moov box位置处理有问题。说白了，就是文件结构稍微不规范，框架就罢工了。
Stagefright的工作流程大致是这样的：
- 数据源读取：从文件或网络流读取数据
- 解封装：分离出音频流和视频流
- 解码：将压缩数据解码为原始数据
- 渲染：将原始数据送到显示设备或扬声器
这里面最关键的，就是解码这一步。解码又分软件解码和硬件解码，我们接下来重点聊这个。
20.2 MediaCodec：硬件编解码的接口
MediaCodec是Android 4.1引入的API，专门用来访问底层的编解码器。它既可以做软件解码，也可以调用硬件加速单元。我个人觉得，MediaCodec是Android多媒体框架里设计得最优雅的部分之一。
为什么这么说？因为它把复杂的编解码过程抽象成了一个状态机。你只需要按照固定的步骤去操作，就能完成编解码任务。
来看一个典型的使用流程：
// 1. 创建解码器
MediaCodec codec = MediaCodec.createDecoderByType("video/avc");
// 2. 配置解码器
MediaFormat format = MediaFormat.createVideoFormat("video/avc", width, height);
codec.configure(format, surface, null, 0);
// 3. 启动
codec.start();
// 4. 循环处理输入输出
while (!isEOS) {
// 获取输入缓冲区
int inputIndex = codec.dequeueInputBuffer(TIMEOUT_US);
if (inputIndex >= 0) {
ByteBuffer inputBuffer = codec.getInputBuffer(inputIndex);
// 填充数据...
codec.queueInputBuffer(inputIndex, offset, size, pts, flags);
}
// 获取输出缓冲区
BufferInfo info = new BufferInfo();
int outputIndex = codec.dequeueOutputBuffer(info, TIMEOUT_US);
if (outputIndex >= 0) {
// 渲染或处理输出
codec.releaseOutputBuffer(outputIndex, true);
}
}
// 5. 停止并释放
codec.stop();
codec.release();这段代码看起来简单，但实际项目中坑不少。我曾经遇到过一个情况：某些芯片的解码器对输入数据的对齐有要求，如果数据没有按照16字节对齐，解码器就直接返回错误。嗯，这种问题在文档里往往不会写，只能靠踩坑积累经验。
小技巧：在配置MediaCodec时，可以调用codec.getCodecInfo().getCapabilitiesForType()来查询当前设备支持的编码参数范围，比如最大分辨率、支持的profile等。这能帮你提前规避很多兼容性问题。
20.3 硬件编解码 vs 软件编解码
说白了，硬件编解码就是把解码工作交给专门的硬件模块去做，比如GPU、DSP或者专用的视频编解码器。软件编解码则是用CPU去跑解码算法。
两者的区别很明显：
| 对比项 | 硬件编解码 | 软件编解码 |
|---|---|---|
| 功耗 | 低（专用硬件效率高） | 高（CPU全速运转） |
| 性能 | 高（轻松处理4K/8K） | 受限（取决于CPU性能） |
| 灵活性 | 低（只支持固定格式） | 高（可以解码各种格式） |
| 延迟 | 较低 | 较高 |
| 开发难度 | 中等（需要处理厂商差异） | 较低（标准API即可） |
在嵌入式设备上，硬件编解码几乎是必选项。你想想看，一个低功耗的ARM Cortex-A系列芯片，用软件解码1080p H.264视频，CPU占用率直接飙到80%以上，设备发热严重，电池也撑不了多久。而用硬件解码，CPU占用率可能只有10%左右。
但是，硬件编解码也有它的麻烦。不同的芯片厂商，实现方式千差万别。高通有OMX，联发科有自己的方案，全志、瑞芯微也各有各的接口。我曾经在一个项目里，为了适配三款不同的芯片，写了三套不同的硬件解码适配层，那段时间真是……嗯，不提了。
20.4 框架图：多媒体数据流
下面这张图，是我自己总结的多媒体数据流走向。从文件读取到最终显示，每一步都离不开前面讲的这些组件。
从这张图可以看得很清楚：数据从源文件进来，经过Stagefright解析器拆成音频和视频两路，然后分别通过MediaCodec调用硬件解码器，最后送到不同的渲染模块。中间的同步机制确保声音和画面不会错位。
20.5 避坑指南：硬件编解码的常见问题
做嵌入式多媒体开发，有些坑是绕不开的。我把自己踩过的几个典型问题分享出来，希望能帮你少走弯路。
坑一：解码器初始化失败
我曾经在一个项目里，MediaCodec的configure方法总是返回错误。查了两天才发现，是因为Surface的格式不匹配。有些芯片要求Surface必须是特定格式（比如RGBA_8888），而默认创建的是RGB_565。解决方案是在创建Surface时明确指定格式。
坑二：解码延迟抖动
硬件解码虽然快，但延迟并不总是稳定的。我记得有一次做实时视频通话，解码延迟忽高忽低，导致画面卡顿。后来发现是解码器的输入缓冲区没有及时填充，导致解码器频繁进入空闲状态。解决办法是保持输入队列有足够的数据缓冲。
坑三：不同芯片的兼容性
这个最头疼。同样是H.264解码，高通芯片支持到High Profile Level 5.1，而某些低端芯片只支持到Main Profile。如果你编码时用了High Profile，在低端芯片上就直接黑屏。我的建议是：在应用启动时，先查询设备的解码能力，再动态调整编码参数。
20.6 实战建议
最后，给正在做嵌入式多媒体开发的朋友几点建议：
- 先软后硬：调试阶段先用软件解码验证流程，再切换到硬件解码。这样能快速定位问题是出在框架层还是硬件层。
- 善用MediaCodec的异步模式：从Android 5.0开始，MediaCodec支持异步回调模式。我个人强烈推荐使用这种模式，代码更简洁，也不容易阻塞主线程。
- 关注厂商的私有扩展：很多芯片厂商会在标准MediaCodec之外提供一些私有接口，比如调整解码器缓存大小、设置低延迟模式等。这些接口往往能解决一些棘手的问题。
- 做好降级策略：当硬件解码失败时，要能自动回退到软件解码。虽然慢一点，但总比黑屏强。
多媒体框架这块内容确实不少，但只要你理解了数据流的走向，掌握了MediaCodec的基本用法，再积累一些实战经验，大部分问题都能迎刃而解。嗯，今天就先聊到这里。
公众号:蓝海资料掘金营，微信deep3321