How to stop screenshare and remove screenshare dialog when browser tab is shared

We use lib-meet-jitsi in our application and stopping screen share only works when a window or screen is shared.

When a browser tab is shared the code to stop the stream doesn’t work:

   await jitsiVideoTrack.dispose();
    await jitsiRoom.removeTrack(jitsiVideoTrack);
    jitsiVideoTrack.stream.getTracks().forEach((track) => track.stop());
    jitsiVideoTrack.track.stop();

Clarification to the question:
The browser screen share dialog is not removed.

Can you try muting it first?

added await jitsiVideoTrack.mute() before dispose() but didn’t work.

What happens, the share doesn’t end at all? Is any excaption thrown?

An exception is not thrown. To clarify the question. stream is removed from the “conference” but we still see the browser’s screen share dialog.

How did you start the share?

  const createScreenShareTracks = async () => {
    try {
      const tracks = await JitsiMeetJS.createLocalTracks({
        devices: ['desktop'],
        firePermissionPromptIsShownEvent: true,
      });
      return tracks.find((track) => track.type === MEDIA_TYPE.VIDEO);
    } catch (error) {
       console.log(error)
    }

in our flow, we add the screen share as another user to the conference. I grab the screen share video track and do conference.addTrack(screenshareVideoTrack)

@jallamsetty do you see anything obviously wrong here?

@saghul @jallamsetty, please do you have any more updates or suggestions on where to look? Thanks

@Mupati dispose should remove the track from the conference and then stop the MediaStreamTrack. Is there any reason why you are repeating the same steps in your code after disposing the JitsiTrack ?
Do you have multi-stream mode enabled on your deployment ? If so, I would recommend muting the track (removes track from pc and then stops the media stream). When you start SS again, you need to call JitsiConference.replaceTrack(mutedTrack, newTrack).
That said, I don’t know why a tab share would behave differently from window/screen share.

I added those additional steps to see if that could remove the screen share since it was not working when a tab is shared.

In our case, we remove the screen share completely and add it afresh so I think we’ll not need replaceTrack.

How do I check whether multi-stream mode is enabled or not?

Multi-stream is enabled by default in the latest stable. You can check the browser console logs to see if it’s enabled or not on your deployment. There is a log that gets printed.

2022-10-27T17:49:22.843Z [FeatureFlags] <Object.init>: Send multiple video streams: true, Source name signaling: true, Unified plan: true

In multi-stream mode, if a video track and desktop track are added to the conference, they need to be muted and unmuted whenever needed. RemoveTrack is essentially replacing the current track with null which is what mute track operation also does.

This is what I have. Means multistream is not enabled.

[FeatureFlags] <Object.init>:  Source name signaling: false, Send multiple video streams: false, SSRC rewriting supported: false, uses Unified plan: true

Then try enabling it please, the non-multi-stream code will be going away soon.

1 Like

In my use case, I create a fresh jitsi to add the screenshare and terminate it when ending the screen share. Does this make a difference?

I don’t add the screen share track to the existing video track. I think I was having an issue related to jitsi not allowing the addition of multiple video tracks.

Also an issue where track_removed is no longer fired: Track.dispose() doesn't call TRACK_REMOVED in the conference - #2 by saghul

I’ve done that.