Re: [mediacapture-screen-share] Auto-pause capture when user switches captured content (#255)

I think we still want to go with a callback rather than an event, so as to avoid the issues with multiple tracks with the same source, and the interaction between multiple listeners.

With that, I don't really see how we could avoid `enableManualSwitching()`, or any method/attribute for setting the callback.

Once a callback is set - using whichever method of attribute - there is no way for the UA to determine if the application wish to receive a new audio track and retain the old video track. Not without additional API surfaces, at any rate, and those are past MVP in my opinion. We need to fire a new video track, and we need to stop delivering frames to the old one (or else they effectively share a source).

I think we have a clear and simple solution in:
* No callback set using `enableManualSwitching()` - old behavior.
* Callback set using `enableManualSwitching()` - the new behavior when the user switches the shared surface is:
   1. Stop delivering frames on the old tracks.
   2. Invoke the callback with the new tracks. Frames might already be flowing on that track.
   3. End the old tracks. (TBD if an onended event should be fired.)

This is future-proof:
* We can extend the API to treat navgiation as a change of surface.
* We can extend the API to handle user interaction with the UA as change of surface. (I am NOT saying that we should. I am only saying that we have the flexibility to consider it.)
* We can extend the API to allow apps to ask for different behavior for video/audio. (E.g. ask the UA to keep the injection-model for one but issue new tracks for the other.)

-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/255#issuecomment-1740762866 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 29 September 2023 11:49:56 UTC