GStreamer 1.16.2 UDP收发not-negotiated(-4)错误及RTSP流转多UDP问题

错误原因 #

• 第一次streaming stopped, reason not-negotiated (-4)报错：接收端配置的RTP CAPS参数不全，缺少时钟频率、帧率等和发送端匹配的参数，两端能力协商失败。
• 第二次could not link udpsrc0 to rtpjpegdepay0报错：你错误将发送端JPEG编码后的裸流CAPS套给了udpsrc，udpsrc接收的是rtpjpegpay封装后的RTP包，CAPS类型必须为application/x-rtp才能和rtpjpegdepay的输入类型匹配，你修改为image/jpeg后类型不匹配，无法完成元件链接。

解决方法 #

1. 先运行带-v参数的发送端管道，打印正确的RTP CAPS：

gst-launch-1.0 -v videotestsrc ! jpegenc ! rtpjpegpay ! udpsink host=127.0.0.1 port=5200

2. 找到日志中类似/GstPipeline:pipeline0/GstRtpJPEGPay:rtpjpegpay0.GstPad:src: caps =后面的CAPS内容，复制填入接收端udpsrc的caps参数即可，通用可用的接收端管道如下：

gst-launch-1.0 udpsrc port=5200 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)JPEG, payload=(int)26, a-framerate=(string)30" ! rtpjpegdepay ! jpegdec ! autovideosink

可以用GStreamer原生的tee元件实现流克隆，全程不做额外编解码，端到端延迟可控制在百毫秒以内，方案如下：

核心逻辑 #

直接拉取RTSP的RTP裸流，用tee复制为多份，每份走独立的UDP套接字发往不同目标，避免多余编解码产生的耗时。

低延迟优化配置 #

• rtspsrc添加latency=0 drop-on-latency=true参数，关闭默认的jitter buffer缓存，超时直接丢帧避免累积延迟
• 所有udpsink添加sync=false async=false参数，关闭时钟同步等待，收到数据包直接发送
• 每个tee分支添加独立queue元件，隔离不同UDP链路的阻塞风险，单条链路抖动不会影响其他链路的发送

示例管道 #

以下示例实现拉取RTSP流后同时发往两个UDP目标：

gst-launch-1.0 rtspsrc location=rtsp://你的RTSP流地址 latency=0 drop-on-latency=true ! application/x-rtp,encoding-name=JPEG,payload=26 ! tee name=t \
t. ! queue ! udpsink host=192.168.1.10 port=5200 sync=false async=false \
t. ! queue ! udpsink host=192.168.1.11 port=5200 sync=false async=false

如果你的RTSP流是H.264/H.265编码，只需要修改caps中的encoding-name对应为H264/H265即可，无需修改其他逻辑。 #

内容的提问来源于stack exchange，提问作者Daniel Lopes