gstreamer的udpsink发送约1000个数据包后停止流式传输

Question

我正在尝试使用gstreamer传输Raspberry Pi相机。这是我的管道：

raspivid --nopreview -ih -hf -vf --width 800 --height 600 --framerate 20 --bitrate 2000000 --profile main --timeout 0 -g 4 -o - | gst-launch-1.0 -vvv fdsrc do-timestamp=true \
 ! h264parse ! omxh264dec ! clockoverlay time-format="%A | %d %B %Y | %H:%M:%S" ! omxh264enc target-bitrate=2000000 control-rate=1 ! h264parse ! rtph264pay config-interval=1 pt=96 ! udpsink host=targethost port=8004 sync=false

而且它的工作原理...差不多好。我可以在目标主机上接收流约一秒钟，然后它停止。 Gstreamer不会输出任何错误，也不会退出，它只是停止发送UDP数据包。

我在Pi上安装了iptraf，可以看到大约1000个数据包后UDP数据包发送停止。它可能会在大约800个数据包或大约1500个数据包处停止，大约在这些数字附近。

现在有趣的是，它有时会工作更长的时间，例如几个小时。但是有时它几乎立即停止。我现在已经观察了大约两天，这可能是它在晚上工作得更好，也许是因为当时的流是黑色的，所以压缩效果更好，发送的数据包更少了吗？我不知道。有什么可以阻止数据包发送而不会出现类似的错误？任何人都知道这里发生了什么吗？

添加了＃1：同样，如果是基础架构问题，Pi会通过其Wi-Fi接口连接到本地网络，并且实际上已连接到Wi-Fi扩展器。因此，这不是一个很干净的设置，但是它似乎可以在晚上运行，至少从最近两天来看，但是即使存在带宽瓶颈，它也可以像这样停止UDP流吗？对我来说这没有意义。

已添加＃2：

$ gst-launch-1.0 --version
gst-launch-1.0 version 1.14.4
GStreamer 1.14.4

已添加＃3：

我用GST_DEBUG=3运行它。当它停止时，它不会显示任何新内容，只会停止显示任何新消息。

这里是完整的输出，直到流死亡而没有任何其他消息：https://pastebin.com/raw/kTfbCW37（即使流在以下所述的某些配置中长时间正常工作，也会出现这些警告）。

我还发现带宽不是问题。我用iperf进行了测量，该流最多仅使用大约1/10的可用带宽。

[我还发现，如果我将分辨率提高到--width 1920 --height 1080，则流似乎可以工作更长的时间...（它在晚上停止在某一点）。因此，发生了一些非常奇怪的事情。有什么想法可能是什么，或者我还能做什么以弄清发生了什么？

Answer 1

我在其他一些“嵌入式”设备上也遇到过类似的情况，因此我将分享从那时获得的经验知识。

就我而言，我通过以下方法成功制作了稳定的视频流：

• 在queue之前添加udpsink元素。 queue将“在源极板上创建一个新线程以解耦接收器和源极板上的处理”，因此，从理论上讲，如果CPU具有多个内核，它将带来好处。在我的情况下，queue“缓冲”高于默认值：

  ... ! queue max-size-time=5000000000 max-size-buffers=10000000 max-size-bytes=50000000 ! udpsink ...

增加buffer-size元素的udpsink属性。例如，

... ! updsink buffer-size=50000000 ...

当udpsink无法足够快地处理数据包时，应允许内核缓冲更多数据包。
就我而言，以上设置可稳定流并缓解基础结构瓶颈。
而且，正如@vermeate所建议的那样，附加调试总是有帮助的：将GST_DEBUG级别设置为更高的值，尝试降低raspivid帧速率，比特率..并观察行为。