- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Sat, 09 Nov 2024 11:13:55 +0000
- To: public-webrtc-logs@w3.org
It does not seem that we are converging, we have more proposals than ever in this thread. I am personally still not sure whether we need to allow asynchronous pausing of frames, maybe we should concentrate on this issue first. Here are a bunch of questions that might be helpful for the above question and how it could interact with `configurationchange`. 1. Should setting synchronously `track.enabled` to false as part of either event handler/callback prevent new surface frames to be provided to all track's sinks (if using a promise to pause, let's say the web app returns `Promise.resolve()`? 2. If we add a new callback/event, what would be the timing of `configurationchange` event listeners? Would it be before, after? If after, would there be a guarantee that frames would not be delivered to sinks at the time the callback is called. 3. In workers, what is the timing of `configurationchange` event vs. exposure of video frames with MSTP? 5. Is it useful to expose deviceIds (https://github.com/w3c/mediacapture-screen-share/issues/308) for this use case? -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/15#issuecomment-2466176195 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 9 November 2024 11:13:56 UTC