Issue with Webrtcsink and differences in Windows and Mac.
I have a straight forward pipeline gst-launch-1.0 rtspsrc location=rtsp://admin2:admin54321@192.168.1.26:10554 ! rtph264depay ! h264parse ! webrtcsink
The signaling server being used is the one present in the signalling folder in gst-plugins-rs. cargo run --bin gst-webrtc-signalling-server
The incoming rtsp stream can be seen on the browser in case of Mac, but not in case of Windows.
In case of windows adding a decoder in the pipeline causes the issue to be resolved but that does not make sense. If it works in Passthrough setup without decode on Mac why does it fail for windows?
On chrome://webrtc-internals i do not see any inbound-rtp/outbound-rtp stats either (windows), even though it says ice candidates connected and stable.
Hi there, the issue is most likely due to differences in how Chrome on Windows handles H.264 within WebRTC compared to Mac. In passthrough mode, the browser must accept exactly the same H.264 profile, level, and stream format coming from the RTSP source. If the camera is using a High or Main profile, SPS/PPS is not being sent correctly, or if the stream-format is not what the browser expects, Chrome on Windows may successfully negotiate the connection (ICE shows “connected”) but still fail to process the video, which is why no inbound-rtp statistics appear. When you add a decoder in the pipeline, the video gets re-encoded into a compatible format allowing it to work properly.
But that would entail the webserver not working when run from mac and observed on a windows machine/browser.
If i start the signalling server, the pipeline and the webserver(built using js) on mac, and have the client of Mac machine (chrome–localhost), it displays video and appropriate inbound-rtp.
At the same time,
If i view the streams of the webserver(hosted on mac) on windows machine client (chrome on that machine), it DOES WORK.
I switch this out to starting the signalling server/pipeline/webserver on windows machine. Everything fails. The same windows machine can’t view it, neither can Mac.
The format, sps/pps negotiated in the pipeline is also the same. The profiles (which all work for the mac machine) do not work for the windows one. Main, High, Baseline, all checked.
Analyzing both .dot files it seems is not a plugins issue or a profile mismatch. Rather, it seems it is an issue with the GstWebRTCBin remains in a ice-gathering state and leads to an error. As the Windows host fails completely I would think is an issue with ice/UDP transport, such as a firewall block, network issue, or a DNS problem. To confirm this, run this pipeline: GST_DEBUG=“webrtc*:6,nice*:6” gst-launch-1.0 -v rtspsrc location=rtsp://admin2:admin54321@192.168.1.26:10554 ! rtph264depay ! h264parse ! webrtcsink stun-server=“stun://stun.l.google.com:19302”. It adds debug messages regarding the WebRTCBinelement and a stun server to confirm if Windows as a host can establish a valid UDP path. Let me know the debug messages that the pipeline outputs.
