- From: Tove Petersson via GitHub <sysbot+gh@w3.org>
- Date: Fri, 12 Apr 2024 09:41:46 +0000
- To: public-webrtc-logs@w3.org
The way I conceptualize these options about whether `stop` should affect just one or both tracks is as follows: 1. Session tracks and surface tracks behave as clones with respect to each other, so `stop` would only affect the track on which it is called. 2. Session tracks are proxy tracks to the underlying surface tracks. Operations done on session tracks will also affect the corresponding underlying surface tracks and vice versa. Calling `stop` on one of the tracks would then affect both tracks. If we choose to treat them as clones (option 1), I think that rather than introducing a special case, it’s better to allow the application to choose which tracks to receive through the opt-in, e.g.: - `surfaceSwitchingMethod: [“inject”]` to only receive session-tracks. - `surfaceSwitchingMethod: [“replace”]` to only receive surface-tracks. - `surfaceSwitchingMethod: [“inject”, “replace”]` to receive both types of tracks. That would avoid creating the extra cloned track in the first place for applications that are only interested in either session tracks or surface tracks. It also does not add any extra burden on application writers since they would need to specify an opt-in anyway. > 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. -- GitHub Notification of comment by tovepet Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/4#issuecomment-2051419238 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 12 April 2024 09:41:47 UTC