Webrtc issues with jetson-utils

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
1

I apologize in advance for what may be a silly mistake on my part.

I am running a jetson-utils container built using the jetson-containers framework, and using ./run.sh, all on an ORIN AGX jetpack 6

I am experimenting with the jetson-utils image streaming:

In terminal 1: video-viewer v4l2:///dev/video0 webrtc://@:8554:my_output
In terminal 2: video-viewer webrtc://@8554:my_output

So, basically experimenting with a simple pipeline. However, when I do this, the receiver (in terminal 2) I get [gstreamer] gstDecoder::Capture() – a timeout…

There a SOUP server warning that (could not listen on address 0.0.0.0, port = 8554: Error binding to address 0.0.0.0:8554: Address already in use), but then it does seem to create the gstDecoder.

When I try to access the source webrtc server from the browser, I get an empty video viewer, and an eventual crash (sinkpad should not be nullptr)

Any help would be greatly appreciated. Jetson-containers is awesome by the way.

2

rtp works as expected.

3

Hi @brbl, thanks, all the networking and connection negotiation with WebRTC can be tricky to debug sometimes (and admittedly the GStreamer plugins for it aren’t super rock solid) - so first, can you try to just get the browser viewer working, before trying the loopback? (and I actually haven’t tested WebRTC loopback before on the same device, which is maybe why you run into that port conflict, and I don’t really see a real circumstance for WebRTC loopback on the same device anyways)

In chrome on your client machine, try disabling chrome://flags/#enable-webrtc-hide-local-ips-with-mdns

See the mDNS resolution issue referred to in this post about that:

5

Well I guess I am not alone. Sorry, I should have checked github issues. For what it is worth, the disable trick did not work for me. BTW, I think I ran into similar issues with rtsp.

Stepping back, I was thinking that using the jetson-utils framework to pass images between containers was better suited for our needs, and more lightweight than deepstream while being more performant than a software only solution (i.e., grpc). Am I thinking about this correctly?

As always, thanks for the quick response! It is greatly appreciated, so thanks!!!

6

OK gotcha - I probably would use some kind of cross-process shared memory pipe or queue to transfer images between container instances. The encoding and IP transport of RTSP/WebRTC has a higher overhead than would be necessary for that (not to mention the reliability)

9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.