Test

背景痛点

在视频会议、直播导播等场景中，画中画合成是刚需功能，但开发者常遇到三个典型问题：

• 解码瓶颈：同时解码 4 路 1080P 流时，CPU 占用率常突破 80%，导致合成帧率骤降
• 内存暴涨：传统的每帧独立处理方式，使得内存峰值达到单路的 4 倍以上
• 音画同步：各输入流 PTS（呈现时间戳）基准不同，合成后出现肉眼可见的唇音不同步

技术选型

对比两种主流方案：

1. FFmpeg overlay 滤镜链
2. 优势：内置支持硬件加速，支持动态调整层叠位置

3. 劣势：复杂滤镜组合时性能下降明显

4. libvpx 多层编码

5. 优势：适合浏览器环境，编码效率高
6. 劣势：需要重新编码，延迟增加 30-50ms

最终选择 overlay 方案，因其：
– 支持硬件直通（Zero-copy）
– 可复用现有解码器资源
– 滤镜参数可实时调整

核心实现

GPU 加速全流程

# 示例：使用 VAAPI 硬件加速的滤镜链初始化
filter_graph = f"""
    [0:v]hwupload,scale_vaapi=w=960:h=540:format=nv12[base];
    [1:v]hwupload,scale_vaapi=w=480:h=270[pip1];
    [base][pip1]overlay_vaapi=x=10:y=10:format=nv12
"""
# 关键参数说明：# hwupload - 上传到 GPU 显存
# scale_vaapi - 硬件缩放
# overlay_vaapi - 硬件层叠合成

PTS 同步策略

1. 绝对值对齐：以首个输入流为基准，其他流做PTS 偏移补偿
2. 主从流同步：动态选择参考流（如选择音频流同步视频）
3. 动态阈值：当差值 >40ms 时强制对齐，避免频繁微调

完整错误处理示例

AVFrame* compose_frames(/*...*/) {int ret = av_buffersrc_add_frame_flags(ctx, frame, AV_BUFFERSRC_FLAG_KEEP_REF);
    if (ret < 0) {
        // 内存不足时自动降级到软件处理
        if (ret == AVERROR(ENOMEM)) {switch_to_software_mode();
            return compose_frames(/*...*/);
        }
        // 其他错误处理逻辑...
    }
}

性能测试

| 分辨率组合 | CPU 占用(%) | GPU 占用(%) | 延迟(ms) |
|——————|————|————|———-|
| 4×1080P→1080P | 78 → 25 | 60 → 72 | 120 → 45 |
| 1×4K+3×720P | 82 → 28 | 65 → 80 | 150 → 50 |

避坑指南

• DRM 内存泄漏 ：通过vainfo -a 检查 GPU 内存分配，注意 ffmpeg 退出时的资源释放
• 滤镜链复用：采用单例模式管理滤镜图，避免重复创建开销
• 安卓兼容 ：必须启用mediacodec 表面模式，禁用纹理缓存

开放问题

当输入流动态增减时，如何实现无缝的滤镜拓扑重构？欢迎在评论区分享你的解决方案。