音视频基础概念与选型前提

2.1 本章边界与输入输出

本章聚焦多媒体工程架构中必须理解的基础概念：采样率、编码格式、容器格式与硬件加速。边界限定在选型前提与原理级认知，不深入编解码器内部实现或驱动层细节。输出为：一张概念关系图、一组选型对比表、以及架构落地所需的步骤与验收标准。

2.2 分层架构与组件职责

在 Android 多媒体管道中，上述概念分布在以下层次：

边界定义：采样率属于采集与数据处理层；编码格式贯穿编解码层；容器格式属于封装层；硬件加速作为横切能力影响编解码与渲染层。

2.3 核心概念详解

2.3.1 采样率

采样率决定单位时间内采集的样本点数，直接影响信号保真度。常见值：8 kHz（电话）、16 kHz（语音）、44.1 kHz（CD）、48 kHz（视频同步）、96 kHz（专业音频）。

• 选型权衡：高采样率带来更大带宽与存储消耗，低采样率可能导致高频信息丢失。
• 风险点：采样率不匹配导致重采样引入失真或延迟；部分硬件加速器对非标准采样率支持不佳。

2.3.2 编码格式

编码格式定义压缩算法，直接影响码率、质量与兼容性。常见编码格式对比：

选型权衡：优先选择硬件加速列表中覆盖率高的格式（如 H.264、AAC），避免 AV1 在全量设备上回退软编导致过热。

2.3.3 容器格式

容器格式负责封装音频、视频、字幕、元数据。常见对比：

2.3.4 硬件加速特性

硬件加速通过专用单元（GPU、DSP、VPU）分担编解码负载。Android 通过 MediaCodec API 提供统一接口，底层选择由 OMX IL 或 Codec2 驱动。

• 控制流：应用层指定 video/avc 等 MIME，底层查询系统编解码器列表，返回支持的加速器。
• 数据流：Surface 输入/输出可绕过 CPU 拷贝，直接渲染到显示。
• 选型权衡：硬件加速降低功耗、提升帧率，但可能裁剪部分 profile（如 H.264 High 10）。部分 SoC 仅支持解码，编码需软编码回退。

2.4 选型权衡总表

2.5 落地步骤

1. 需求定义：确定目标码率、分辨率、音频带宽、延迟预算。
2. 设备画像：通过 MediaCodecList 枚举当前设备支持的所有编码器/解码器及硬件加速标志。
3. 测试矩阵：至少覆盖 5 款主流 SoC（高通、联发科、三星、华为、Tensor）的采样率与编码组合。
4. 选型固化：建立代码内策略表（如下），动态选择。

// 伪代码：选型策略示例
if deviceHasHardwareAAC() {
    audioCodec = "audio/mp4a-latm"
    sampleRate = 48000
} else {
    audioCodec = "audio/mp4a-latm" // 软编 fallback
    sampleRate = 44100
}

if deviceHasHardwareH265() {
    videoCodec = "video/hevc"
} else if deviceHasHardwareH264() {
    videoCodec = "video/avc"
} else {
    videoCodec = "video/avc" // 软编 fallback
}

container = "video/mp4" // 首选

2.6 验收标准

• 采样率正确性：录制/播放时实际采样率与配置偏差 < 1‰。
• 编码格式兼容：在目标设备集合上，指定编码格式的编解码成功率 100%（软/硬均可）。
• 容器格式完整性：生成的 MP4 文件可在系统播放器、Chrome、VLC 中正常播放，音画同步误差 < 10ms。
• 硬件加速性能：编解码帧率 ≥ 目标帧率的 90%，CPU 占用率较软编降低 ≥ 40%。
• 信任链路验证：硬件加速 fallback 流程无 crash，日志中能正确标记硬编/软编路径。