- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 01 Mar 2024 19:13:38 +0000
- To: public-webrtc-logs@w3.org
> I don't fully understand what is being asserted here. A clarification would be welcome. It's asserting that injection and its alternative have different side-effects, and which ones an app prefers might differ based on what surface the end-user chose to switch to/from (e.g. whether both or neither have audio). E.g. - If the sink is MediaRecorder, injection allows continuing to record to the same (e.g. video only) file, but it remains an app decision whether to do so (perhaps denoting a chapter in some metadata), or to sometimes or always switch recording to a new (e.g. audio and video) file - If the sink is RTCRtpSender, injection allows immediate switching with `replaceTrack` without waiting for a renegotiation round-trip, but it remains an app decision whether to take advantage of this and how to handle edge-cases (e.g. audio) > > A late decision seems inherently needed to fix this glitch for the subset of same-type switching. > > Does that mean you support dropping the late-decision requirement for non-same-type switching? I've seen no proposal for how an app might specify its preferences for the different surfaces a user might pick up-front, but am happy to compare complexity of anything presented. > Applications built before cross-surface-type source-switching was possible had no reason to expect that getSettings().displaySurface might be mutable, and they are not robust to these changes. How are they not robust to these changes? Do you have an example that is not experimental? -- 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-1973772716 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 1 March 2024 19:13:39 UTC