- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Sat, 23 Oct 2021 00:45:37 +0000
- To: public-webrtc-logs@w3.org
@youennf Privacy indicators and temporary permissions are [tied to the context that created it]( https://w3c.github.io/mediacapture-extensions/#transferable-mediastreamtrack). The track objects themselves are not expensive, as the [cloning steps](https://w3c.github.io/mediacapture-main/#track-clone) reveal. They are mere (ref-counted) handles to the singular underlying source. > Also, contrary to VideoFrame, a live track with event listeners might not be easy to GC. If the concern is accidental clones, then event handlers aren't an issue. JS adding event handlers registers an interest. The JS is on the hook to call `track.stop()` when it is finished with a track. That's already the contract. > Having an explicit cloning step allows keeping the number of live tracks low. How so? Why is `structuredClone(track)` any different from `track.clone()` in this regard? I agree it can be a hassle for apps to keep track of clones, but I don't see this moving the needle one way or the other. > My question is why supporting it outright? Simpler spec and model. Developers can already do `stream.clone()` and get a cloned stream containing clones of all tracks. This should fall out naturally with structuredClone, which would support other collections as well. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/823#issuecomment-950029086 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 23 October 2021 00:45:39 UTC