基于Linux的嵌入式视频流传输：用GStreamer实现低延迟RTSP推流

安防摄像头、无人机图传、工业视觉检测——这些嵌入式场景对视频流的共同要求是：低延迟、稳定、跨平台。GStreamer作为Linux上最成熟的管道式多媒体框架，天然适合在资源有限的ARM平台上搭建RTSP推流服务。本文将演示如何用GStreamer从摄像头采集、编码到RTSP推送，并给出关键的延迟优化参数。

GStreamer核心概念：Pipeline

GStreamer将处理流程拆解为一系列Element（元件），通过Pad连接成Pipeline（管道）。一个典型的推流Pipeline包含四个环节：

Source → Convert → Encode → Payload → Sink

Source：视频源，如v4l2src（USB摄像头/MIPI CSI）

Convert：色彩空间转换/尺寸缩放，如videoconvert、videoscale

Encode：视频编码器，如x264enc（软件）或v4l2h264enc（硬件）

Payload：封装为RTP包，如rtph264pay

Sink：网络输出，如udpsink或rtspclientsink

最简单的推流命令

假设你有USB摄像头（/dev/video0），通过软件编码推送到RTSP服务器：

gst-launch-1.0 v4l2src device=/dev/video0 ! \

   video/x-raw,width=640,height=480,framerate=30/1 ! \

   videoconvert ! \

   x264enc speed-preset=ultrafast tune=zerolatency ! \

   rtph264pay config-interval=1 ! \

   tcpserversink host=0.0.0.0 port=8554

这条命令在本机开启了TCP服务，客户端可用rtsp://192.168.1.100:8554/test拉流。但注意：tcpserversink只是一个简单的TCP sink，真正的RTSP服务器需要额外的信令处理。更专业的做法是用rtspclientsink推送到外部RTSP Server（如Live555或MediaMTX）：

gst-launch-1.0 v4l2src ! videoconvert ! x264enc ! rtph264pay ! \

   rtspclientsink location=rtsp://server_ip:554/live/stream

低延迟的关键参数

嵌入式平台性能有限，延迟主要来自编码缓冲和网络抖动。以下参数组合可将端到端延迟控制在100ms以内：

gst-launch-1.0 v4l2src ! \

   video/x-raw,width=640,height=480,framerate=30/1 ! \

   videoconvert ! \

   queue max-size-buffers=0 max-size-time=0 ! \      # 禁用队列缓冲

   x264enc speed-preset=ultrafast tune=zerolatency \

            key-int-max=15 bitrate=1024 ! \           # 每15帧一个关键帧

   rtph264pay config-interval=-1 ! \                  # 每个包都带SPS/PPS

   udpsink host=192.168.1.2 port=5000 auto-multicast=0 \

            sync=false async=false                    # 禁用同步，立即发送

逐项解释：

speed-preset=ultrafast：牺牲压缩率换取编码速度

tune=zerolatency：强制编码器不缓存未来帧

key-int-max=15：减少GOP长度，降低解码端启动延迟

sync=false：不让GStreamer等待时钟同步，数据到了就发

queue max-size-buffers=0：避免内部缓冲堆积

硬件编码：解放CPU

多数ARM SoC（如Rockchip RK3588、Allwinner V系列）自带H.264/H.265硬件编码器，通过V4L2 M2M接口暴露。使用硬件编码可将CPU占用率从80%降到10%以下：

gst-launch-1.0 v4l2src ! \

   video/x-raw,width=1280,height=720 ! \

   videoconvert ! \

   v4l2h264enc extra-controls="encode,h264_level=13,h264_profile=4" ! \

   rtph264pay ! \

   udpsink host=192.168.1.2 port=5000

硬件编码器的延迟通常比软件更低（1-2帧缓冲），但需要注意驱动和GStreamer插件的兼容性。使用v4l2-ctl --list-formats-ext确认编码器支持的格式。

嵌入式部署注意事项

内存：GStreamer pipeline中每个元素都可能申请buffer，建议用capssetter限制分辨率，避免OOM。

网络：RTSP over UDP容易丢包，可改用TCP模式：rtspclientsink protocols=tcp。

热插拔：摄像头意外断开会导致pipeline停止，可用autovideosrc代替v4l2src，或使用restart策略。

日志：设置环境变量GST_DEBUG=3查看pipeline状态，GST_DEBUG=v4l2src:5过滤特定元素。

实测效果

在RK3568平台上（4核A55），使用v4l2h264enc编码1080p@30fps，通过Wi-Fi推流到PC播放器，端到端延迟稳定在80-120ms。若改用软件编码x264enc，延迟相当但CPU占用飙升至70%，且偶有丢帧。

写在最后

GStreamer的灵活性在于你可以像搭积木一样组合各种元件：添加音频用alsasrc，叠加文字用textoverlay，录制回放用filesink。对于嵌入式RTSP推流，核心原则是减少缓冲、优先硬件编码、禁用同步。掌握这几个参数，你的嵌入式设备就能拥有媲美专用编码盒的低延迟视频能力。