Re: [mediacapture-transform] We shouldn't require track transferability (#113)

> > Nothing of the sort. The proposal is basically adding a new factory method for MSTP /VTG. No need to remove anything
> 
> If we are not removing the existing API, why adding an API that can be shimed on the existing API?

It's a bit more than a factory method. For comparison, here's a trivial factory function ([works](https://jsfiddle.net/jib1/94Lmqse0/) in Safari):
```js
async function createVideoTrackGeneratorAndProcessor(worker, track) {
  const before = track.clone();
  worker.postMessage({before}, [before]);
  const {data} = await new Promise(r => worker.addEventListener("message", r));
  return data.after;
}
```
But this differs from what @guidou seems to want: the worker reacting to `track.applyConstraints()` on the main thread (or  wherever it is transferred I suppose?) That doesn't exist today.

Having processing react to tracks on other threads seems more complex than requiring the track to be on the same thread (Safari [stops](https://jsfiddle.net/jib1/cuyo3h25/) processing if the `before` track is transferred away).

It feels like we haven't thought past main thread here. Asking websites to postMessage constraints seems simpler.


-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/113#issuecomment-2537491988 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 12 December 2024 00:38:01 UTC