如何构建GStreamer低延迟RTSP→UDP→RTSP流媒体转发管道？

核心问题点 #

• 冗余解码引入延迟与流损坏：当前接收端管道做了avdec_h264解码操作，把H264流转成原始视频帧后再推给MediaMTX。这不仅会增加1-2秒的解码/重新编码延迟，还会因为格式转换破坏原流编码参数，导致ffplay绿线、VLC无法读取的问题。
• MediaMTX输入格式不匹配：MediaMTX接收RTSP推流时，期望的是标准H264编码流，而非解码后的原始视频帧。强制推送原始帧会让rtspclientsink自动重新编码，进一步引发流兼容性问题。
• rtspsrc读取MediaMTX流失败：大概率是读取管道参数或MediaMTX配置问题，比如未指定正确流格式，或者MediaMTX的流路径配置错误。

优化实现方案 #

方案1：直接转发RTP H264流到MediaMTX（推荐） #

发送端管道保持不变：

gst-launch-1.0 rtspsrc location='rtsp://XXXX:XXXXX@192.168.2.68/axis-media/media.amp' latency=0 ! \
rtph264depay ! \
h264parse ! \
rtph264pay config-interval=1 ! \
udpsink host=127.0.0.1 port=5005 sync=false

接收端跳过解码步骤，直接把UDP的RTP H264流封装成RTSP推给MediaMTX：

gst-launch-1.0 udpsrc port=5005 buffer-size=200000 caps="application/x-rtp, media=(string)video, encoding-name=(string)H264, payload=(int)96" ! \
rtpjitterbuffer do-lost=true latency=100 ! \
rtspclientsink protocols=tcp location=rtsp://127.0.0.1:8554/media1.amp latency=0

该方案保留原流编码参数，消除了解码带来的延迟，同时大幅提升流兼容性。

方案2：UDP传输H264裸流，接收端封装RTSP推送 #

发送端改为输出H264裸流（省去RTP封装）：

gst-launch-1.0 rtspsrc location='rtsp://XXXX:XXXXX@192.168.2.68/axis-media/media.amp' latency=0 ! \
rtph264depay ! \
h264parse ! \
udpsink host=127.0.0.1 port=5005 sync=false

接收端读取UDP裸流，重新封装成RTP后推给MediaMTX：

gst-launch-1.0 udpsrc port=5005 ! \
h264parse ! \
rtph264pay config-interval=1 ! \
rtspclientsink protocols=tcp location=rtsp://127.0.0.1:8554/media1.amp latency=0

这种方式更轻量，适合网络带宽有限的场景。

解决rtspsrc读取MediaMTX流失败的问题 #

尝试用指定格式的管道读取：

gst-launch-1.0 rtspsrc location=rtsp://127.0.0.1:8554/media1.amp latency=0 ! \
rtph264depay ! \
h264parse ! \
avdec_h264 ! \
videoconvert ! \
autovideosink sync=false

如果仍失败，检查MediaMTX配置文件，确保paths/media1.amp的source设置为rtsp://localhost:8554/media1.amp，且MediaMTX服务正常运行。

额外注意事项 #

• 除非网络丢包严重，否则尽量减少queue2这类缓冲组件的使用，避免增加延迟。
• 推流到MediaMTX时使用protocols=tcp，可避免UDP丢包导致的流损坏，适合本地或稳定网络环境。
• 追求低延迟的话，发送端和接收端的latency参数尽量设为100ms以内，同时保持sync=false关闭同步延迟。

内容的提问来源于stack exchange，提问作者Marco Carandente