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

> > You can call applyConstraints and read stats/settings on Window, where the main application is.
> 
> Yes, but waiting on postMessage for these measurements hardly seems ideal. 

That goes the other way too if you want access to the track on Window (which is the more common case today).

> In the current spec, the worker transform can inspect real-time [track stats](https://w3c.github.io/mediacapture-extensions/#dom-mediastreamtrackvideostats) counters like `deliveredFrames`, `discardedFrames` and `totalFrames` synchronously, and correlate them with the `VideoFrame` it is currently processing.

I'm not opposed to supporting transferability.  I'm opposed to making it a requirement to use mediacapture-transform, as that will have the practical consequence of delaying interoperable implementations.

We already have a pattern for adding worker support without requiring transferability of tracks or streams. This doesn't mean applications are forbidden from transferring tracks on browsers that support it if they want to.
It just means that applications that don't need to transfer tracks to do processing (which are most if not all applications today) can more quickly have an interoperable API in practice.


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


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

Received on Tuesday, 15 October 2024 13:06:25 UTC