4、视频采集与解码：使用GStreamer进行视频采集、硬件解码加速、多路视频流管理
好，咱们进入第四章。视频采集与解码，这是整个流水线的入口。说白了，视频源都拿不到，后面分析个啥？
我个人习惯，在边缘设备上首选GStreamer。为什么？因为它成熟、灵活，而且对硬件加速的支持非常到位。你想想看，一个树莓派或者Jetson Nano，CPU就那么点算力，如果全靠CPU软解，4路1080p就能把CPU吃满，哪还有余力跑AI模型？
4.1 GStreamer基础管线
先看一个最简单的例子。从USB摄像头采集视频，显示到屏幕上：
gst-launch-1.0 v4l2src device=/dev/video0 ! videoconvert ! autovideosink这条命令干了三件事：
- v4l2src：从Video4Linux2设备读取数据
- videoconvert：做色彩空间转换
- autovideosink：自动选择合适的显示窗口
嗯，这里要注意。实际项目中，我们很少直接用gst-launch。更多是用GStreamer的API，在代码里动态构建管线。我在一个智慧安防项目里，就吃过硬编码管线的亏——换了个摄像头型号，色彩格式不对，画面直接花屏。
4.2 硬件解码加速
这才是重头戏。边缘设备上，硬件解码器通常叫decoder或者vpudec。以NVIDIA Jetson系列为例，它提供了nvv4l2decoder这个元件。
对比一下软解和硬解的性能差异：
| 解码方式 | CPU占用率 | 功耗 | 延迟 | 路数(1080p@30fps) |
|---|---|---|---|---|
| 软解(avdec_h264) | 85%-95% | 高 | 30-50ms | 2-3路 |
| 硬解(nvv4l2decoder) | 5%-15% | 低 | 5-10ms | 8-12路 |
看到了吧？硬解把CPU解放出来，专门跑AI推理。我曾经在一个项目中，用软解跑4路视频，CPU直接飙到98%，推理帧率掉到2fps。换成硬解后，CPU降到12%，推理帧率稳定在25fps。差距就是这么大。
硬解管线示例：
gst-launch-1.0 \
rtspsrc location=rtsp://admin:pass@192.168.1.100:554/stream1 ! \
rtph264depay ! h264parse ! \
nvv4l2decoder ! nvvidconv ! \
video/x-raw,format=BGRx ! \
videoconvert ! video/x-raw,format=BGR ! \
appsink name=mysink注意最后那个appsink。这是GStreamer和应用程序之间的桥梁。解码后的BGR图像，会通过appsink送到你的Python或C++代码里，再喂给AI模型。
nvv4l2decoder，树莓派用v4l2h264dec，RK3588用mppvideodec。写代码时一定要做平台适配。
4.3 多路视频流管理
多路管理，核心就三个字：复用。你不能为每路视频单独开一个进程，那样资源开销太大。正确的做法是：
- 线程池 + 事件循环：每个视频流一个线程，但共享同一个解码器池
- 动态增删流：支持运行时添加或移除视频源
- 流状态监控：断流自动重连，超时报警
我建议用GstBus来监听每路流的状态。比如这样：
# 伪代码示意
def on_bus_message(bus, message, pipeline):
if message.type == Gst.MessageType.EOS:
print("流结束，准备重连")
pipeline.set_state(Gst.State.NULL)
pipeline.set_state(Gst.State.PLAYING)
elif message.type == Gst.MessageType.ERROR:
err, debug = message.parse_error()
print(f"流错误: {err}, 调试信息: {debug}")
# 记录日志，触发告警多路流的管理，我习惯用一个字典来维护：
| 流ID | URL | 状态 | 解码器 | 帧率 | 最后活跃时间 |
|---|---|---|---|---|---|
| cam_01 | rtsp://192.168.1.10/stream1 | PLAYING | nvv4l2decoder | 30fps | 2024-01-15 14:32:18 |
| cam_02 | rtsp://192.168.1.11/stream1 | ERROR | nvv4l2decoder | 0fps | 2024-01-15 14:30:05 |
每秒钟检查一次这个字典。如果某路流超过5秒没有新帧，就触发重连逻辑。我曾经遇到过摄像头电源松动，导致画面卡住但不断流的情况。光靠GstBus的ERROR信号不够，还得配合帧率监控。
4.4 实战中的避坑指南
最后，分享几个我踩过的坑：
- RTSP超时：默认超时时间可能太长。设置
rtspsrc timeout=5，5秒连不上就放弃。 - 内存泄漏：GStreamer的buffer引用计数要小心。每从appsink拿一帧，记得
unref。 - 分辨率不匹配：解码后的分辨率可能和预期不同。用
videoscale强制缩放，但注意这会增加延迟。 - 色彩格式：AI模型通常要BGR，但摄像头输出可能是NV12或I420。中间加一层
nvvidconv或videoconvert做转换。
嗯，这一章就到这里。视频采集和解码是基础，但基础不牢，地动山摇。下一章，我们聊聊怎么把解码后的帧高效地送到AI推理引擎里。