Hi there, we're seeing what seems to be a potential bug in Firefox when using the screen sharing functionality in Hubs, causing the video stream to not be sent over the wire.
Note that at the time of this writing screen sharing seems completely broken in Firefox Nightly, this bug seems manifest in Firefox 68.0.2.
- Go to hubs.mozilla.com and create a room
- Open up a new private browser window at the same URL as your new room. You should now have two browser windows open to the new room.
- In the first window, click through the entry flow by clicking "Enter Room" at the bottom, accepting the default avatar, "Enter on Screen", granting microphone permission, and "Enter Room" on the audio page.
- In the second window, you should see the avatar of the first window (and hear their audio over the microphone if you selected one.)
- In the first window, click the screen sharing button -- at the top center of the screen there is a small HUD, it is the button farthest to the left that looks like a computer monitor.
- Select a window to share and confirm.
- In the both windoww, you should now see the shared screen appear in the room.
- In the first window, click the screen sharing button again to end sharing.
- In the second window, you should see the shared screen disappear.
- In the first window, click the screen sharing button again to begin sharing the screen again. Choose the same window.
- In the first window, you will see the screen appear as expected. In the second window, you will see a black square where the screen should be.
The underlying logging in our SFU, and the about: webrtc logging implies there is no data being sent over the WebRTC video stream after the second share. This bug occurs if you use either screen sharing or camera sharing. This bug does not happen in chrome, with either screen sharing or camera sharing. (At the time of this writing, screen sharing in chrome via getDisplayMedia is not currently released yet at hubs.mozilla.com, but local testing showed that this issue does not occur when doing screen sharing from Chrome.)
Under the hood, the way the tracks are managed in Hubs are as follows:
We have two RTCRtpSenders, one for the audio track and one for the video track going to our SFU. After the first share, both are enabled.
After you remove the first share, we set the video track's enabled bit to false on the corresponding sender.
When the second share is created, we call replaceTrack() on the sender, passing it the new video track.
It seems possible something is going wrong during replaceTrack, or something upstream is going wrong (or we are failing to do something properly) when tearing down the first track. Given that it is working properly in Chrome, it seemed possible that it was a browser bug so I opened this issue. Unfortunately I could not figure out how to get the debug logging working for webrtc (the about:webrtc debug logging button shows no log file name when I enable debug mode, and the environment variable in the wiki did not seem to help.)
Thanks for any help!