Eyevinn / webrtc-player

WebRTC (recvonly) player
MIT License
87 stars 18 forks source link

Player auto-reconnect on loss of WHIP Client video #29

Closed georgewoofbates closed 1 year ago

georgewoofbates commented 1 year ago

I am implementing the example player with the Eyevinn WHIP Client. All works when sending video to the from the client to the player via Cloudflare Stream.

If I disconnect the client (ie close the tab) and then start streaming again from the Client without closing the Player window, I can see in the debug logs on the player the video stats stop receiving, and then start receiving again, but the player window stays black. It doesn't seem to reload the video stream when the Client re-connects to the player.

birme commented 1 year ago

Thank you for this report.

marcusspangenberg commented 1 year ago

Hi @georgewoofbates, Do I understand it correctly that you keep the player connected while reloading the WHIP client and starting a new WHIP session?

I haven't tried with cloudflares WHIP endpoint, but from the protocol itself there is no method of starting a stream with an old resource identifier. Do they have some other method of reconnecting to the same WHIP resource or associating a new WHIP resource with an existing channel- or stream identifier?

How a new WHIP resources reusing a channel- or stream identifier is handled on the distribution end is going to be implementation dependant, and there is no guarantee that the restarted stream will reach the already connected WHEP players. Most likely WHEP players would have to reset the connection and start over if they detect loss of media or a WebRTC disconnect event.

georgewoofbates commented 1 year ago

Hi @marcusspangenberg, thanks for your informative reply.

I wasn't aware that's how the protocol worked in that there was no method of reconnecting to the same WHIP resource. A couple of quick questions:

1) When I have been testing this, once the player looses media, I don't get the WebRTC-player sendAnswer response: 409 error in the terminal until around 30 seconds after the picture has frozen. Is there a way I can get this faster to know the client has been disconnected? 2) Would there be anyway of using a secondary WebSocket connection to share the resource/stream identifier between the client and player to be able to re-connect on loss of connection? 3) With the Eyevinn WebRTC Player, what's the best way to detect loss of media? I have the statsTypeFilter: "^candidate-*|^inbound-rtp" enabled in the player config, but this doesn't throw any errors or messages when loss of media occurs.

marcusspangenberg commented 1 year ago

I think the best approach here is to add events or callbacks to WebRTCPlayer so that the code using the player instance can be notified if

  1. The RTCPeerConnection transitions to the failed state
  2. The RTCPeerConnection is still in the connected state, but no media has been received for a certain amount of time.
georgewoofbates commented 1 year ago

Thanks for all your hard work on this guys. Looking forward to integrating it!

birme commented 1 year ago

This is now available in v0.10.0