- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 12 Nov 2024 22:38:41 +0000
- To: public-webrtc-logs@w3.org
> > 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()?
>
> Yes.
Yes. This is why I think a callback is appropriate. It's a synchronization window with two-way guarantees:
1. The UA MUST NOT produce frames between the switch and the callback being called
2. The UA MUST take JS state on callback return / promise resolve into account when deciding to resume frames
Events normally don't carry the second guarantee. The [configurationchange](https://w3c.github.io/mediacapture-extensions/#change-track-configuration) event is also subject to _"fuzzing"_, making it a questionable event to overload for timing sensitive information.
> 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.
No, I'd leave [configurationchange](https://w3c.github.io/mediacapture-extensions/#change-track-configuration) alone. It has none of these guarantees. Fires after. Anything else can be polyfilled:
```js
controller.surfaceSwitchingCallback = async () => {
await new Promise(r => referenceTrack.onconfigurationchange = r);
worker.postMessage({paused: referenceTrack.getSettings()});
await new Promise(r => worker.onmessage = r);
});
```
An upstream frame delay callback untangled from tracks. KISS
--
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-2471736692 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 12 November 2024 22:38:42 UTC