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

> There is nothing magical about FPWDs such that they cannot be improved.

Well, we are very far from FPWD, the spec reached consensus within the WebRTC WG and has been very stable for a few years now.
This design cannot come as surprise since both editors of this spec are from Google.
Also, there will be soon two implementations. This should prove that the current spec is implementable and precise enough to get interop. This would allow to move the spec to REC.

> The use case where the application needs the track on Window is a convincing one.

So far, I have not seen a usecase where the API you propose is providing more than the existing API. Could you be more specific?

For instance, the API you are proposing is most probably shimable using the current API.
The reverse is not true.

Taking a real example to compare the two APIs as an exercise, we could take the use case of doing real time encoding and sending of a video track to the network (using data channel, web transport, or the future encoded source proposal). This requires the web page to potentially adapt the frame rate and/or resolution to the network conditions.

With the current API, the adaptation logic is all happening solely in the worker via `applyConstraints`.
With the proposed API, the web application would have to postMessage to the window environment, which is doable but more complex and suboptimal.

> Doesn't seem particularly fine to me.
> Properly supporting lots of real-world applications using MediaStreamTrack on Window would seem better to me.

Could you precise what use case and what advantages you see?
My understanding is that both APIs will roughly have a similar level of functionality.

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


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

Received on Wednesday, 11 December 2024 15:45:31 UTC