- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 31 Oct 2024 14:50:50 +0000
- To: public-webrtc-logs@w3.org
> I think there is consensus on the requirement to control when new surface frames are sent via a peer connection. This issue is in screen capture so there are 4 sinks to consider: HTMLVideoElement, MediaRecorder, RTCRtpSender, and MediaStreamTrackProcessor. Is the requirement the same for these? > A second discussion point is whether it is better to pause at track level or to pause globally. We should to decide which of these two behaviors we want. Tracks can't pause today. It might conceptually generalize to e.g. readwrite `track.paused`, and maybe `track.onpause`. What we seem to be talking about as the synchronous model is ways for web developers to make due without these. But the workarounds web developers would need to use on the regular seem borderline unreasonable (clone, stop, replaceTrack-hop, or MSTP+VTG worker roundtrip). So far no other sources need pausing. So the only benefit would be to pause some tracks longer than others. This benefit seems marginal to me. Extending pausing for a subset of tracks also seems possible through the same workarounds floated. Captured Surface Switching happens at the source and is unique to this source. So pausing where the switch happens seems inherently simpler for web developers to understand. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/15#issuecomment-2450082332 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 31 October 2024 14:50:51 UTC