- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Thu, 31 Oct 2024 08:23:47 +0000
- To: public-webrtc-logs@w3.org
> This is why I recommended we nail down requirements first I think there is consensus on the requirement to control when new surface frames are sent via a peer connection. One discussion point is whether the synchronous event model is sufficient or not to support this requirement (this is what we are debating here). A second discussion point is whether it is better to pause at track level or to pause globally. I am not sure we clearly decided one way or the other. Wrt pausing with the synchronous model, two solutions have been found so far (MSTP/VTG and track.ended). A third solution is to use `setParameters` to set `active` to false, which, according my interpretation of the spec, should work (although spec is pretty light at the moment). We could check how implementations are doing by racing setParameters and postMessaging to a worker to enqueue a VideoFrame in a VTG stream. It seems getting interop there might be a good idea. I would also think that calling MediaRecorder.pause() synchronously would work. Again, spec is a bit light in terms of VideoFrame management. FWIW, choosing the `configurationchange` model does not mean we would never allow asynchronous pausing. We could introduce per track pausing via `ConfigurationChangeEvent.waitUntil`, which might be a useful addition for other tracks than gdm in the future. > is it a bug? See [w3c/webrtc-pc#3014](https://github.com/w3c/webrtc-pc/issues/3014). AFAIK, all browsers behave the same here. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/15#issuecomment-2449298599 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 08:23:47 UTC