gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-03 17:27:00 26 4
gpt4 key购买 nike

我正在尝试使用 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 数据包。

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

现在有趣的是,有时它的工作时间更长,比如几个小时。但有时它几乎立即停止。我现在观察了大约两天,可能是它在晚上工作得更好,也许是因为那时流是漆黑的,所以压缩得更好,它要发送的数据包更少?我不知道。什么可以停止数据包发送而不会出现任何错误?有人知道这里发生了什么吗?

添加#1:
此外,如果是基础设施问题,Pi 通过其 wi-fi 接口(interface)与本地网络连接,并且它实际上连接到 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然后流似乎工作时间更长......(它在晚上的某个时间停止)。所以发生了一些非常奇怪的事情。任何想法可能是什么,或者我还能做些什么来弄清楚发生了什么?

添加#4:
我安装了 pv并将其放在 raspivid 之间和 gstreamer .事实证明,这最终可能不是 gstreamer 的问题,因为看起来来自 raspivid 的流只是在某一点停止。一旦它停止在发送 1.99GiB 的数据(这让我认为这与旧的、已知的 raspivid 的 2GB 限制有关),但第二次它停止在发送的 775MiB 数据。

最佳答案

我在其他一些“嵌入式”设备上遇到过类似的情况,所以我将分享当时获得的经验知识。

就我而言,我成功地通过以下方法制作了一个稳定的流:

  • 添加 queue udpsink 之前的元素. queue将“在源焊盘上创建一个新线程以解耦接收器和源焊盘上的处理”,因此,理论上,如果 CPU 具有多个内核,它应该会带来好处。就我而言 queue “缓冲”高于默认值:
    ... ! queue max-size-time=5000000000 max-size-buffers=10000000 max-size-bytes=50000000 ! udpsink ...
  • 增加buffer-size udpsink 的属性(property)元素。例如,
    ... ! updsink buffer-size=50000000 ...

  • 当 udpsink 无法足够快地处理数据包时,应该允许内核缓冲更多数据包。

    就我而言,上述设置稳定了流并缓解了基础设施瓶颈。

    而且,正如@vermeate 所建议的,额外的调试总是有帮助的:将 GST_DEBUG 级别设置为更高的值,尝试降低 raspivid帧率,比特率..并观察行为。

    关于udp - gstreamer 的 udpsink 在发送约 1000 个数据包后停止流式传输,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/59769247/

    26 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com