05. FFmpeg 与 GStreamer 实战

FFmpeg 更适合检查媒体、批处理、转码和通过 C/C++ API 控制编解码；GStreamer 更像可组合的 Pipeline 框架，用 Element、Pad、Caps 和 Bus 连接采集、转换、编码、显示与网络。OpenCV 主要处理图像和视觉算法，OpenGL/OpenGL ES 主要负责渲染，它们通常和 FFmpeg 或 GStreamer 协作，而不是互相替代。

先检查，再改变

对未知输入先使用 ffprobe，确认轨道、Codec、时间基和像素格式。命令行能复现后，再把同一组输入和参数迁移到应用或设备；否则 C/C++ API 中出现的错误很难区分是媒体问题还是程序问题。

ffprobe -hide_banner -show_streams -show_format input.mp4
ffmpeg -hide_banner -encoders | grep -E '264|265|hevc'

-c copy 只复制已有压缩码流：

ffmpeg -i input.mp4 -map 0 -c copy output.mkv

如果目标容器不接受原有 Codec 或时间戳，转封装会失败，需要调整流映射、添加 bitstream filter 或改为转码。每次改变后用 ffprobe 对比输入输出的 Codec、帧数、时长和时间基。

文件模拟直播

把文件按原始时间戳推到 RTMP 入口，可以验证服务端接入、转协议和播放器链路：

ffmpeg -re -i input.mp4 -c copy -f flv \
  rtmp://SERVER/live/test

-re 限制读取速度，使文件接近实时发送；它不提供摄像头的曝光、采集抖动或硬件编码行为。测试结束后应删除临时流和凭据，避免把实验入口暴露到公网。

转码与质量比较

H.264 转 H.265 必须解码并重新编码：

ffmpeg -i input.mp4 \
  -c:v libx265 -crf 28 -preset medium \
  -c:a copy out-hevc.mp4

比较时固定输入、分辨率、帧率和质量目标，记录编码耗时、输出大小、平均/峰值码率、CPU/RSS、丢帧和主观或客观画质。只看“文件变小”不能说明转码更好；CRF、预设、场景复杂度和播放端支持都会影响结论。

GStreamer Pipeline

先用测试源确认 Pipeline 语义，再换成真实摄像头：

gst-launch-1.0 videotestsrc num-buffers=90 \
  ! videoconvert ! fakesink

真实链路通常是：

V4L2 capture → colorspace/scale → hardware encoder
             → muxer or RTP/RTSP → sink/display

每个箭头都要确认 Caps、内存类型和时间戳。videoconvert 或颜色转换可能产生额外内存复制；硬件编码器是否接收 DMABUF、是否需要特定 stride，要看目标插件和驱动文档。

RK3588 的落地边界

一个可验证的排查顺序是：

1. 用 V4L2 查询摄像头的 fourcc、分辨率和 buffer 能力。
2. 用软件路径跑通采集、转换和文件输出，记录 CPU 与帧率基线。
3. 再接入 MPP 或发行版提供的硬件编解码插件，比较 CPU、RSS、队列深度和端到端延迟。
4. 若要显示，单独确认 DRM/KMS；若要播放音频，单独确认 ALSA 设备和 PCM 格式。
5. 最后才组合成 RTSP、HLS 或 WebRTC 服务，并保留每层的日志和时间戳。

“支持 FFmpeg”或“支持 GStreamer”只说明软件接口存在，不能替代目标板上的插件、驱动、固件和实测。完整的设备树、BSP 和驱动排查入口见嵌入式 Linux。

完成这组基线后，再把参数、协议和硬件加速组合成具体产品方案；每次只改变一个变量，才能知道性能或延迟变化来自哪一层。