- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 16 Apr 2024 16:29:32 +0000
- To: public-webrtc-logs@w3.org
Note I inadvertently wrote _"hardware light"_ among my concerns above, but of course this is screen-capture not camera/mic, so the only user-observable side-effect of an unstopped track would be the prolonged appearance of whatever privacy indicators the browser shows for a couple extra seconds until GC happens (e.g. after a user clicks stop).
> > Option 1 makes sense to me, UA will likely optimize the case of no event handler for `newsource`
>
> I don’t think this optimization would work in the other direction, i.e., for applications that are only interested in surface tracks.
That's seems fine, as this optimization would be there to solve today's apps unaware of the `newsource` event.
In contrast, apps uninterested in session tracks can simply stop them once they've received new surface tracks:
```js
const sessionStream = await getDisplayMedia({controller, /*opt-in*/, ...});
video.srcObject = sessionStream;
controller.onnewsource = event => {
sessionStream.getTracks().forEach(track => track.stop()); // idempotent
video.srcObject = event.stream; // surface tracks
};
```
So there doesn't seem to be much need for new stop semantics, which seems nice.
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/4#issuecomment-2059492708 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 16 April 2024 16:29:33 UTC