- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Mon, 23 May 2022 09:03:58 +0000
- To: public-webrtc-logs@w3.org
> I humbly disagree. I believe I have argued the point. It seems we are stuck on this complexity assessment. I hope we agree though that Chrome's current implementation is putting additional complexity on the web page shoulders for the sake of this optimisation. > You gave two examples. I gave examples where pause is not required. Your third example is a generalisation of the second example, where pause is not required, at least to the apps I can think of. > If I were to implement this app, I'd see a click from the user as telling me: (i) stop capturing (and/or transmitting-remotely) the old target's content and (ii) start capturing the new target's content. I'd pause the track until (ii) is completed. I do not see what would drive user to expect pausing here. I would think VC apps tend to not follow that pattern, they prefer a seamless transition. replaceTrack is suited for that seamless transition to go from old track to new track. Also replaceTrack is a chained operation: it was thought fine to delay a bit switching the sources. This probably mean that some limited switch latency is fine for most WebRTC applications. If the app is so keen to do that kind of optimisations, they can do it on their side in a faster way than any UA-side optimizations: - When getting getDisplayMedia track, clone the track and call cropTo on the cloned track. - When user clicks, switch to either the original or the clone, synchronously. No need to do any pausing. > This depends on the the app; it would only matter to some. I still do not understand which apps would actually want to do what you described, and for which reasons. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1134391947 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 23 May 2022 09:04:00 UTC