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.
> 

That there are two implementations doesn't prevent changing the spec to improve it. We do that all the time with specs that are much more mature than this one.

> > 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?
> 

All existing applications  today (including the ones that do video processing) currently do so with the tracks on Window, where they manage all the logic. Forcing them to migrate to manage the track in the worker is an unnecessary barrier.


> 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.
> 

That sounds more like a hypothetical example than a real one. Either way, my proposal supports it fine. There is nothing that prevents transferring the track to the worker in my proposal, so saying that some use case works better when you transfer the track is not an argument against the proposal.

You would have to show evidence that forcing the transfer of the track is better in all, or at least most use cases, than making it optional.


> > 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.

The spec version forces a pattern of transferring a track and managing its lifetime there, while historically all applications manage tracks on Window. My proposal makes it easy to support both. Forces the transfer of the track to the worker is a not necessarily a good pattern, especially for existing applications.

The use case is all existing applications.


-- 
GitHub Notification of comment by guidou
Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/113#issuecomment-2536399906 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:59:47 UTC