CODEWITHSUNDEEP
c++cwebrtcgstreamerh.264
Arjan
Arjan

Reputation: 619

Gstreamer H264 UDP -> WebRTC Restreaming

I have a Ricoh THETA Z1 360 degrees camera that outputs a 4K 360 stream. I'm using their own libuvc-theta-sample for retrieving the video stream and getting it into Gstreamer. I've used the following pipeline to sink the video stream to a different machine on my network that runs a Gstreamer application that restreams udpsrc into a webrtcbin:

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

On my receiving end this works perfectly fine: enter image description here

As you can see I'm using a WebRTC bin that sinks the video to a WebRTC browser client.

This is all working as expected as long as I'm on localhost. If I try to reach the video stream from a different machine in my network, it does the ICE and SDP offers perfectly, the WebRTC connection is established, but no video is shown. If I replace my pipeline with a pipeline that depays, decodes, and re-encodes the H264 stream, it works perfectly fine. Obviously, this is not what I want because I'm losing (significant) video quality and it takes time to re-encode.

Something that might help discover the issue is the following log that gets spammed in my console. This log doesn't appear when I'm viewing the stream from localhost, but it does appear when trying to view the stream from a different machine within my network.

0:00:07.248383000 22700 00000139F5F3E340 INFO h264parse gsth264parse.c:3741:gst_h264_parse_src_event: received upstream force-key-unit event, seqnum 253 running_time 99:99:99.999999999 all_headers 0 count 0 0:00:07.559580000 22700 00000139F5F3E340 INFO h264parse gsth264parse.c:3741:gst_h264_parse_src_event: received upstream force-key-unit event, seqnum 254 running_time 99:99:99.999999999 all_headers 0 count 0 0:00:07.854883000 22700 00000139F5F3E340 INFO h264parse gsth264parse.c:3741:gst_h264_parse_src_event: received upstream force-key-unit event, seqnum 255 running_time 99:99:99.999999999 all_headers 0 count 0 0:00:08.160170000 22700 00000139F5F3E340 INFO h264parse gsth264parse.c:3741:gst_h264_parse_src_event: received upstream force-key-unit event, seqnum 256 running_time 99:99:99.999999999 all_headers 0 count 0 0:00:08.414529000 22700 00000139F5F3E340 INFO h264parse gsth264parse.c:3741:gst_h264_parse_src_event: received upstream force-key-unit event, seqnum 257 running_time 99:99:99.999999999 all_headers 0 count 0 0:00:08.715480000 22700 00000139F5F3E340 INFO h264parse gsth264parse.c:3741:gst_h264_parse_src_event: received upstream force-key-unit event, seqnum 258 running_time 99:99:99.999999999 all_headers 0 count 0 0:00:09.013550000 22700 00000139F5F3E340 INFO h264parse gsth264parse.c:3741:gst_h264_parse_src_event: received upstream force-key-unit event, seqnum 259 running_time 99:99:99.999999999 all_headers 0 count 0

I've thought about NAT traversal issues with STUN and TURN, but it wouldn't make sense as my Google Chrome WebRTC internals page shows that the WebRTC connection is successfully established. Besides, it does work when re-encoding the stream.

I'm failing to understand why it is working on localhost, but not on other machines within my network. Perhaps someone can shed some light on why it's not working.

Upvotes: 5

Views: 2585

Answers (2)

8-DK
8-DK

Reputation: 301

  1. Disable firewall on streaming server and client machine then test streaming works or not. If works then you can add your firewall rules for WebRTC and UDP ports . 2)Try streaming with creating direct tunnel using ngrok or other free service with direct IP addresses. Then go with STUN and TURN setup.

Also try following pipeline:

    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

Upvotes: 2

SeB
SeB

Reputation: 1616

Not sure at all for your case, but you may try adding rtpjitterbuffer with a few frames latency in the remote case:

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

Upvotes: 0

Related Questions