- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Fri, 29 Sep 2023 08:53:29 +0000
- To: public-webrtc-logs@w3.org
Thanks, Youenn; I believe this summary is mostly accurate. [*] > we should consider removing step 4 (closing the old tracks). The web application could decide to stick with the old tracks and stop the new tracks instead if it is thought more adequate. > > This would allow easy migration in the simple cases (just do nothing for video, check for new audio). I don't think this would work, because the old track would not get any new frames, even if it's ended. I'm also not sure what problem it's solving - if an existing application is already updated to call `enableManualSwitching()`, and it already does work on the new audio track, why can't it also do work on the video track? (In contrast to backwards compatibility with existing applications that don't update their code and never call `enableManualSwitching()`; it's preferable to ensure that these just keep working.) > We could have a simple CaptureController onswitch event, given it would not have any side effect. Minor objection on my part here. I don't think I'd block on it, but I'd want a chance to argue against it, at a time that would not distract us away from the main discussion. --- [*] With some nits. For example, I don't currently see why it's necessary to mandate that no new frames be emitted on the new track before the old one is ended. But I think that's a minor point that can be discussed later. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/255#issuecomment-1740541323 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 29 September 2023 08:53:31 UTC