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

> Here are some developer requirements that are well known to us and which are ignored by the current version of the spec (not all of these are related to the issue we're discussing which is track transferability as a mediacapture-transform requirement):

Let's only talk about the requirements that are relevant to this particular issue (audio support and processing on window are out of scope).

> * Keeping the gUM track on Window while processing on Worker (before/after view and other use cases that require track sinks available only on Window)

The before/after view can be implemented by transferring a clone of the track instead of transferring the track itself.

> * Easy feature detection (without requiring the creation of a Worker)

@jan-ivar provided a feature detection approach that works in Safari (and will likely work in Firefox).
This is good enough in practice, feature detection does not have to be technically pure.

I am sympathetic to the needs of browser implementors. So far though, I haven't seen new information that warrants revisiting the design of this API.
Also, this API shape has mostly remained untouched for several years, probably since the spec first public working draft and reached consensus at the time within the WebRTC WG. This API shipped in one UA, and is being implemented in another UA.

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


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

Received on Tuesday, 29 October 2024 16:38:01 UTC