Open wryun opened 10 months ago
Hello, yes, from the user point of view your observation is absolutely right, the browser currently takes some seconds before detecting errors and starting the reconnection procedure, and this is caused by the upgrade from Websockets to WHEP.
Prior to WHEP, there was a permanent Websocket connection from the browser to the server. In case of errors, this connection was closed and the browser was able to detect it immediately.
With WHEP, there is no permanent connection anymore except for the WebRTC peer connection, which may not be able to detect disconnections immediately.
The switch from Websocket to WHEP was performed since WHEP is a documented standard that provides interoperability between different software, while Websocket is not. However, there are side effects.
I have to check whether the server-side peer connection implementation sends QUIT messages when the connection is closed, and whether those messages are enough for the browser to detect the disconnection. If this is the case, we can improve the responsiveness.
Hello, when i switch from MediaMTX v0.22 to ver 1.4.0, I start the webrtc stream and it delays 5s to start it. I have found that WHEP API response slowly. Does anyone know how to solve it ?.
Which version are you using?
v0.22 -> 1.3
Which operating system are you using?
Describe the issue
With MediaMTX v0.22, if a WebRTC stream dropped out it would detect it in the frontend almost immediately and start trying to reconnect. With 1.3 - related to the change from websockets to WHEP? - the receiver JS takes a number of seconds to realise that the stream is no longer there before trying to reconnect.
Describe how to replicate the issue
Did you attach the server logs?
no
Did you attach a network dump?
no