webrtc - unstable connection

dusty-nv / jetson-inference

Hello AI World guide to deploying deep-learning inference networks and deep vision primitives with TensorRT and NVIDIA Jetson.

MIT License

7.69k stars 2.96k forks source link

Hello @dusty-nv,

I am working on webrtc with a jetson orin on a custom board with on-semi MIPI cameras, and it works pretty well most of the time.

The command I use is : video-viewer csi://0 webrtc://@:8555/output --input-width=1920 --input-height=1080 --input-rate=60.0 --stun-server disabled --headless

It works most of the time on chromium or edge, but I noticed many instabilities on the webrtc server :

sometimes a connection can go wrong and then it is impossible to connect a new peer
if there is a peer connected that works perfectly and another peers tries to connect on safari (which does not work), it breaks the first peer stream and it can no longer reconnect, the video-viewer has to be restarted
sometimes after too many bad connections, even restarting the video-viewer does not fix it, but the entire machine has to be restarted : bad server clean-up ?

Also the webrtc server only works when he's initiating the webrtc communication, did you design it like so on purpose ? Will you make it so that the browser initiates the connection ?

Thank you in advance for your help.

Hi @evrdub , unfortunately the webrtc plugins in gstreamer are pretty complex and not what I'd call production-grade robust, and its pretty over my head to dig in with a custom implementation. There is also RTP/RTSP and I believe DeepStream and Video Storage Toolkit in Jetson Platform Services have more stable versions.

I do end up using this WebRTC in a lot of stuff though, and although it has gotten fairly reliable, yes I do notice some quirks now and then - like with the connection refresh (although that seems to work for the most part) In my experience, using chrome with chrome://flags#enable-webrtc-hide-local-ips-with-mdns works the best (although I also test now and then in Safari). I think some of the connection issues come from mDNS and avahi-daemon not resolving .local domains super robustly, and in general WebRTC seems to encounter corner-cases using it LAN-only (as it was architected for STUN/TURN negotation and transport over WAN)

If you're able to dig into this and find any potential solutions or bug fixes, I'd be happy to test changes and accept PRs, unfortunately I don't really have the bandwidth myself to dive super deep into it as one could spend a full-time job just on WebRTC 🤣

dusty-nv / jetson-inference

webrtc - unstable connection #1875