- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 22 Sep 2023 11:36:11 +0000
- To: public-webrtc-logs@w3.org
> 1. Works with all websites without needing their support (user benefits) Agreed, new tracks require extra work for the web developer, it is appealing to keep using the current track from this point of view. This would require an addtional API to allow delaying the generation of frames, typically as part of the `onswitch` event. As of the source mutating, `configurationchange` event may be good enough to tell the web application that cropTo might no longer work for instance. This would require deprecating `BrowserCaptureMediaStreamTrack` as well. The new track approach main benefit is that it is future proof however the model evolves. Another example that comes to mind is if switching from one window to several windows (hence several video tracks, with potentially several audio tracks?). In that case, applications will anyway need to deal with new video tracks if they want to leverage the user selection. > ```js > stream.onaddtrack > ``` I am not a big fan, given many websites do tend to recreate MediaStreams on the fly or clone them. In the future, we might want to transfer MediaStream as well. The application would also need to stick to both CaptureController and the MediaStream for being notified of what is happening. Since we already have CaptureController, I tend to prefer having a single event telling the application what happened all at once. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/255#issuecomment-1731270622 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 22 September 2023 11:36:13 UTC