之前在 RK 平台上搞过音视频的应该都有体会——V4L2 采集、MPP 编解码、RGA 图像处理、DRM 显示，这些底层接口个个都是硬茬，自己从零把它们串起来又累又容易踩坑。FFMedia 的思路就是把这些能力封装成一个个可组合的模块，像搭积木一样拼出一条音视频处理链路。研究了一圈文档和示例，把核心能力整理出来分享给大家。
一、这是个什么？
简单说，FFMedia 是一个面向 Linux 多媒体应用的模块化音视频处理框架，重点适配了 Rockchip 平台的 V4L2、MPP、RGA、DRM/KMS、EGL/GLES 这些硬件能力。
它把摄像头、文件、网络流、应用内存的采集，以及解复用、编解码、图像处理、推理、显示、录制、推流这些环节，统统抽象成了可组合的模块。说白了，就是给实时媒体管线和嵌入式多媒体应用准备的一套"乐高"。
二、模块化管线：像搭积木一样拼链路
这是 FFMedia 最核心的设计。它把摄像头、文件、RTSP/RTMP、编解码器、RGA 图像处理、GPU 图像处理、DRM 显示、推流、录制等能力统一封装成模块。模块之间用生产者/消费者模型连接，只需要关心数据往哪流、配几个参数就行。
所有链路都可以套这个模型来理解：
输入源 VI -> 处理模块 VP -> 输出模块 VO
官方给的几个例子，基本覆盖了常见需求：
RTSP 拉流 -> MPP 硬件解码 -> DRM 低延迟显示
Camera 采集 -> MPP 硬件编码 -> RTSP/RTMP 推流
文件读取 -> 解封装/解码 -> RGA/GPU 缩放旋转 -> 显示或重新编码保存
多路视频 -> Video Stack 拼接 -> 显示或编码推流
项目同时提供了 C++ 示例和 Python 绑定。想快速验证功能、或者急着接业务，用 Python 很快；要做产品级开发、抠性能，用 C++。这点考虑得挺周到。
三、硬件加速：把 CPU 解放出来
FFMedia 重点适配了 Rockchip 的硬件能力：视频编解码走 MPP，图像的缩放、裁剪、格式转换、合成走 RGA 或 GPU。
为啥强调这个？做过音视频的都知道，纯靠 CPU 软解软编，多路视频一上来 CPU 直接拉满，机器烫得能煎蛋，还撑不了长时间运行。走硬件加速链路，CPU 占用能显著降下来，这才适合多路视频、7x24 小时运行、边缘设备部署这些场景。
从文档看，典型能用在这几类业务：
- 多路 RTSP 拉流、解码、显示
- 摄像头采集后实时编码推流
- 视频缩放、旋转、格式转换、画面合成
- 多路视频拼接输出
- 视频转码、封装转换、本地录制
- 解码后接 RKNN 推理，做检测、跟踪这类 AI 视频分析
最后这条我比较感兴趣——解码后直接接 RKNN 做推理，等于把音视频管线和 AI 分析串起来了，这在边缘 AI 场景很实用。
四、参数统一 + 可扩展
两个对开发者比较友好的设计：
- 参数系统统一：模块配置都靠参数描述，同一套参数名称、类型、层级，在 C++、Python、命令行里通用。也就是说在命令行调通的参数，换到代码里名字是一样的，不用记两套。
- 可扩展：大部分场景直接组合现成模块就够了；真有特殊需求，可以继承
ModuleMedia自己实现数据源、处理器或输出模块，扩展路径是通的。
五、高实时性：低延迟数据是亮点
这块是 FFMedia 最想秀的肌肉。低延迟来自硬件编解码 + 模块化管线 + 缓冲队列控制 + 显示链路优化这一套组合拳。官方 README 给的低延迟显示测试数据：
- HDMI 输入转发显示：从 HDMI 输入到转发显示，平均延迟约
29ms - Camera 采集转发显示：从采集到转发显示，平均延迟约
19ms - 通过调整显示时序和屏幕刷新率，能把显示延迟波动从约
1ms~17.6ms压到约1ms~7ms
19ms 的采集转发延迟，对实时性敏感的场景相当能打了。像视频监控、远程操控、低延迟预览、工业视觉、边缘 AI 视频分析、多媒体转发这些，基本都是它的目标场景。
有在用这个框架的朋友，欢迎评论区交流踩坑经验。