使用GstSharp在WPF中显示RTP流报not-linked错误
问题定位
报错not-linked (-1)和caps配置无关,核心原因是pipeline链路断裂:
- 你只完成了
videoconvert -> videosink这最后一段的元素连接,前面创建的udpsrc、rtph264depay、avdec_h264三个元素虽然被加入pipeline,但互相之间没有做链接,RTP数据从udpsrc输出后没有下游元素接收,流直接被终止。 - 之前RTSP场景能正常运行,是因为
rtspsrc是动态输出pad的元素,你原有逻辑里通过PadAdded事件做了动态链路连接;但裸UDP RTP场景下udpsrc是固定静态pad,不需要动态pad处理,必须手动按解码顺序逐个连接所有元素。 - 现有caps配置过于简略,虽然gst-launch命令行下自动协商可以正常工作,但代码场景下补全caps字段可以避免偶发的格式协商失败。
修复方案
1. 补全全链路元素连接
修改CreatePipeline方法中的链接逻辑,按数据流向依次连接所有元素:
_pipeline.Add(_uriDecodeBin, _depay, _avdec, _videoConvert, _videoSink); // 按udpsrc -> depay -> 解码器 -> 格式转换 -> 渲染sink的顺序逐段链接 if (!_uriDecodeBin.Link(_depay)) { Log("udpsrc 无法连接 rtph264depay", LogLevelFlags.FlagFatal); return; } if (!_depay.Link(_avdec)) { Log("rtph264depay 无法连接 avdec_h264", LogLevelFlags.FlagFatal); return; } if (!_avdec.Link(_videoConvert)) { Log("avdec_h264 无法连接 videoconvert", LogLevelFlags.FlagFatal); return; } if (!_videoConvert.Link(_videoSink)) { Log("videoconvert 无法连接视频渲染sink", LogLevelFlags.FlagFatal); return; }
2. 补全udpsrc的caps配置
修改CreateElements方法中udpsrc的caps定义,明确指定RTP流的媒体类型、编码格式,避免协商失败:
_uriDecodeBin = ElementFactory.Make("udpsrc", "source"); _uriDecodeBin["port"] = 5600; // 补全RTP caps必要字段,和推流端rtph264pay的输出格式对齐 var caps = Gst.Global.CapsFromString("application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264,payload=(int)96"); _uriDecodeBin["caps"] = caps; _depay = ElementFactory.Make("rtph264depay", "depay"); _avdec = ElementFactory.Make("avdec_h264", "avdec");
3. (可选)启用硬件解码降低CPU占用
如果要使用你代码里定义的d3d11h264dec硬件解码器,需要调整链路,去掉多余的videoconvert元素:
硬件解码器输出的是D3D11显存中的硬件帧,可以直接被
d3d11videosink接收,不需要经过videoconvert做CPU侧的格式转换,CPU占用会比软解低80%以上。
调整后的链路为:udpsrc -> rtph264depay -> d3d11h264dec -> d3d11videosink,对应代码修改为:
// 解码器替换为d3d11硬件解码 _avdec = ElementFactory.Make("d3d11h264dec", "d3d11dec"); // 链接时跳过videoconvert,直接把解码器连到videosink if (!_avdec.Link(_videoSink)) { Log("d3d11h264dec 无法连接 d3d11videosink", LogLevelFlags.FlagFatal); return; }
内容的提问来源于stack exchange,提问作者Kemsa
相关产品推荐
相关产品推荐

