Gstreamer H264 UDP -> WebRTC 重流

Gstreamer H264 UDP -> WebRTC Restreaming

提问人:Arjan 提问时间:3/8/2022 更新时间:11/15/2022 访问量:1901

问:

我有一台 Ricoh THETA Z1 360 度相机,可以输出 4K 360 度流。我正在使用他们自己的视频流来检索视频流并将其放入 Gstreamer。我使用以下管道将视频流接收器到网络上的另一台机器上,该机器运行 Gstreamer 应用程序,该应用程序将 udpsrc 重新流式传输到 webrtcbin 中:libuvc-theta-sample

appsrc name=ap ! queue max-size-buffers=1 leaky=downstream ! h264parse ! rtph264pay ! udpsink host=192.168.1.137 port=1935 qos=false sync=false

在我的接收端,这工作得很好:enter image description here

正如你所看到的,我正在使用一个 WebRTC bin 将视频下沉到 WebRTC 浏览器客户端。

只要我在本地主机上,这一切都按预期工作。如果我尝试从网络中的另一台机器访问视频流,它可以完美地完成 ICE 和 SDP 提供,建立 WebRTC 连接,但没有显示任何视频。如果我将我的管道替换为对 H264 流进行 depay、解码和重新编码的管道,它工作得很好。显然,这不是我想要的,因为我正在失去(显着的)视频质量,并且重新编码需要时间。

可能有助于发现问题的是以下日志,该日志在我的控制台中收到垃圾邮件。当我从 localhost 查看流时,不会显示此日志,但在尝试从网络中的另一台计算机查看流时,它会出现。

0:00:07.248383000 22700 00000139F5F3E340 INFO h264parse gsth264parse.c:3741:gst_h264_parse_src_event:收到上游 force-key-unit 事件,seqnum 253 running_time 99:99:99.9999999999 all_headers 0 计数 0 0:00:07.559580000 22700 00000139F5F3E340 INFO h264parse gsth264parse.c:3741:gst_h264_parse_src_event:收到上游 force-key-unit 事件,seqnum 254 running_time 99:99:99.9999999999 all_headers 0 计数 0 0:00:07.854883000 22700 00000139F5F3E340 INFO h264parse gsth264parse.c:3741:gst_h264_parse_src_event:收到上游 force-key-unit 事件,seqnum 255 running_time 99:99:99.9999999999 all_headers 0 计数 0 0:00:08.160170000 22700 00000139F5F3E340 信息 h264parse gsth264parse.c:3741:gst_h264_parse_src_event:收到上游 force-key-unit 事件,seqnum 256 running_time 99:99:99.9999999999 all_headers 0 计数 0 0:00:08.414529000 22700 00000139F5F3E340 INFO h264parse gsth264parse.c:3741:gst_h264_parse_src_event:收到上游 force-key-unit 事件,seqnum 257 running_time 99:99:99.9999999999 all_headers 0 计数 0 0:00:08.715480000 22700 00000139F5F3E340 信息 h264parse gsth264parse.c:3741:gst_h264_parse_src_event:收到上游 force-key-unit 事件,seqnum 258 running_time 99:99:99.9999999999 all_headers 0 计数 0 0:00:09.013550000 22700 00000139F5F3E340 INFO h264parse gsth264parse.c:3741:gst_h264_parse_src_event:收到上游 force-key-unit 事件,seqnum 259 running_time 99:99:99.9999999999 all_headers 0 计数 0

我已经考虑过 STUN 和 TURN 的 NAT 遍历问题,但这没有意义,因为我的 Google Chrome WebRTC 内部页面显示 WebRTC 连接已成功建立。此外,它在重新编码流时确实有效。

我不明白为什么它在 localhost 上工作,但在我网络中的其他机器上不起作用。也许有人可以阐明为什么它不起作用。

C++ C、 WebRTC、 Gstreamer H.264

评论

0赞 Lundin 3/8/2022
这与(C或C++)编程有什么关系?
0赞 Arjan 3/8/2022
它是用 C 和 C++ 编写的
1赞 Nordine Lotfi 3/12/2022
不是答案,但在 github 上发现了一些类似的问题:这里有一对可能适合/有帮助的问题。

答:

0赞 SeB 3/16/2022 #1

完全不确定您的情况,但您可以尝试在远程情况下添加具有几帧延迟的 rtpjitterbuffer

... ! udpsrc port=1935 ! application/x-rtp,encoding-name=H264 ! rtpjitterbuffer latency=500 ! rtph264depay ! ...

评论

0赞 Arjan 3/18/2022
感谢您的帮助,但这并没有解决我的问题
2赞 8-DK 3/18/2022 #2
  1. 在流媒体服务器和客户端计算机上禁用防火墙,然后测试流媒体是否有效。如果有效,则可以为 WebRTC 和 UDP 端口添加防火墙规则。 2)尝试使用ngrok或其他具有直接IP地址的免费服务创建直接隧道进行流式传输。然后进行 STUN 和 TURN 设置。

另请尝试以下管道:

    webrtcbin name=sendrecv bundle-policy=max-bundle
        udpsrc port=7001 caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! rtph264depay !
        h264parse ! rtph264pay config-interval=-1 !
        queue ! application/x-rtp,media=video,encoding-name=H264,payload=96 ! rtpjitterbuffer ! sendrecv