无法通过GStreamer接收MJPEG RTP组播流故障排查

问题背景 #

在Jetson Nano上使用以下GStreamer管道推流1080P 30fps的JPEG视频到组播地址：

gst-launch-1.0 -vvvvv v4l2src device=/dev/video2 ! image/jpeg,width=1920,height=1080,framerate=30/1 ! rtpjpegpay ! udpsink host=224.1.2.3 port=8556

推流端调试输出显示各环节Caps匹配正常，RTP封装参数正确。

客户端能检测到约50Mbps的组播流量，但运行以下接收管道无图像输出：

gst-launch-1.0 -vvvvvv udpsrc address=224.1.2.3 port=8556 ! application/x-rtp, encoding-name=JPEG, payload=26 ! rtpjpegdepay ! jpegdec ! videoconvert ! videoscale ! autovideosink

接收端仅输出到jpegdec的sink端日志，无后续解码输出和视频窗口，且帧率显示为0/1。UDP包分析显示：包带有Don't Fragment（DF）标志，但单包长度仅1442字节，远小于1080P JPEG单帧的实际大小；将分辨率降至相机最小值后，偶尔能显示单帧但无法持续播放。使用的相机为Arducam UC-684（2MP 1080P IMX291低光照鱼眼USB相机）。

核心问题分析 #

1. UDP分片丢失：1080P JPEG单帧大小通常在1-5MB，rtpjpegpay会将其拆分为多个RTP包传输。但当前推流的UDP包设置了DF标志，网络设备无法对超过MTU（以太网默认1500字节，有效载荷约1472字节）的包进行分片，导致大帧的分片被直接丢弃，客户端无法拼接完整JPEG帧，自然无法解码显示。
2. 帧率标识异常：接收端显示0/1帧率是因为RTP流未正确传递帧率元数据，但这不是无法显示的核心原因。

修复方案 #

方案1：关闭UDP的DF标志 #

在推流端的udpsink中添加参数，允许网络设备对UDP包分片，确保所有帧分片能到达客户端：

gst-launch-1.0 -vvvvv v4l2src device=/dev/video2 ! image/jpeg,width=1920,height=1080,framerate=30/1 ! rtpjpegpay ! udpsink host=224.1.2.3 port=8556 do-not-fragment=false

方案2：适配MTU调整RTP包大小 #

手动设置rtpjpegpay的mtu参数，让RTP包有效载荷不超过MTU限制（推荐设为1400，留足协议头余量），避免触发分片：

gst-launch-1.0 -vvvvv v4l2src device=/dev/video2 ! image/jpeg,width=1920,height=1080,framerate=30/1 ! rtpjpegpay mtu=1400 ! udpsink host=224.1.2.3 port=8556

方案3：硬件加速优化（可选） #

如果客户端是NVIDIA平台，使用硬件加速解码器替代jpegdec，提升解码效率同时修复帧率传递问题：

gst-launch-1.0 -vvvvvv udpsrc address=224.1.2.3 port=8556 ! application/x-rtp, encoding-name=JPEG, payload=26 ! rtpjpegdepay ! nvjpegdec ! nvvidconv ! autovideosink

额外排查点 #

• 检查客户端与Jetson Nano之间的防火墙规则，确保允许UDP 8556端口的组播流量通过。
• 用tcpdump或Wireshark抓包，确认所有RTP分片都能到达客户端，无丢包情况。

内容的提问来源于stack exchange，提问作者Stanislav Svědiroh