GStreamer mpegtsmux&x2B；udpsink，发送方脱机时重启速度非常慢

我正在流式传输H264 mp4文件序列，而不使用UDP上的mpegtsmux重新编码。我以前在通过UDP传输原始RTP H264时遇到问题，所以我切换到MPEGTS，这对我来说更好

我现在唯一的问题是，当发送方有间隙时，接收方有时需要很长时间才能赶上（挂在前一帧上）。有时甚至是20秒，有时几乎是瞬间。我需要这个尽快。当通过RTP传输h264时，它就是这样工作的，但不幸的是，它产生了不同的问题

这是我的发送管道（使用

gst-launch-1.0

）：

接收方：

udpsrc uri=udp://238.0.0.1:1234 buffer-size=65535 caps=\"application/x-rtp, clock-rate=90000, pt=33\" timeout=1000000000 ! rtpmp2tdepay ! tsparse ! tsdemux ! queue ! decodebin ! autovideosink"

我没有使用rtpjitterbuffer，因为它给我带来了多个问题。虽然流运行良好，但我只需要在decodebin之前添加一个队列

接收端是使用<代码> GSTPARSESEA启动<代码>的C++应用程序，它给了我一些操纵流的可能。

我记录了来自管道的所有消息，我可以看到，发送端一恢复，

GST\u MESSAGE\u元素

消息“

pat

”就来自

mpegtparse

，但是在接收者开始播放流之前有一个巨大的延迟（多秒），有时我甚至看到从流中接收到

GST\u MESSAGE\u TAG

消息，但仍然没有播放。 当它最终开始播放时，所有接收方都在同一时刻播放，好像有什么事件触发了它，但我在日志中没有看到任何内容

我试着使用发送方的

mpegtsmux

参数，如

pmt interval

等，但没有改变，这不是发送方的故障，因为当接收器在中流启动时，它几乎立即开始播放

因此，我开始寻找在接收端丢失数据时重新启动接收端的方法，我在

udpsrc

中添加了

timeout

参数，当发送方停止流式传输时，我可以成功地看到超时消息，然后，当从

mpegtparse

接收到第一个

pat

时，我尝试以多种方式重新启动接收器，但运气不佳。以下是我尝试过的方法：

取消重新填充管道并将其状态设置为NULL，然后重新创建它。这起到了作用，但产生了一些内存泄漏，并且引用未被清除（每次重新启动时，数字都在增加，即，

udpsink1

，

udpsink2

等）

在超时后接收第一个数据时，将管道置于NULL&播放状态，但这导致了一个关于udpsrc未链接的错误

在超时和下一次

GST\u MESSAGE\u STATE\u更改时将管道置于暂停状态

将其置于播放状态。这是有效的，但没有产生任何影响，因为延迟是相同的。我可以看到收到的

pat

消息，状态设置为播放，但管道实际上会在几秒钟后改变状态，然后开始正确播放（因此有一些东西阻止管道播放，从而导致延迟）。我也试着在玩之前寻找0，但还是一样

当我重新启动接收进程时，问题并没有出现——它会立即出现，因此管道中一定有某种东西让管道等待，而不是继续。我还注意到，流隙越长，接受者追赶的时间就越长，但如果接受者最终赶上，那么所有接受者都会同时赶上

是否有任何方法可以强制管道重新启动或删除所有以前的流信息，并从新数据重新开始

udpsrc uri=udp://238.0.0.1:1234 buffer-size=65535 caps=\"application/x-rtp, clock-rate=90000, pt=33\" timeout=1000000000 ! rtpmp2tdepay ! tsparse ! tsdemux ! queue ! decodebin ! autovideosink"