- From: guidou via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Dec 2024 15:16:05 +0000
- To: public-webrtc-logs@w3.org
> > Again I ask, why is this a problem. Is encoded transform non-idiomatic? > > Encoded transform is bespoke. > In what way that doesn't apply here? > > Should we eliminate the RTCRtpScriptTransform constructor and introduce a new transferable object there to be used with postMessage, or make senders and receivers transferable? > > No, because unique tradeoffs were involved, and that [FPWD](https://lists.w3.org/Archives/Public/public-webrtc/2021Sep/0000.html) has already shipped in two browsers. > There is a similar tradeoff here. There is nothing magical about FPWDs such that they cannot be improved. > > Or is it a problem here, but not there? > > I believe it's on the person filing the issue to produce a convincing problem that needs fixing. Otherwise I see no new information since [FPWD](https://lists.w3.org/Archives/Public/public-webrtc/2022Feb/0024.html) that warrants revisiting the design of this API. > The use case where the application needs the track on Window is a convincing one. Basically, that describes all applications using MediaStreamTrack on the Web today. > Usage of the spec API seems fine, as seen in [this blog](https://blog.mozilla.org/webrtc/unbundling-mediastreamtrackprocessor-and-videotrackgenerator). Doesn't seem particularly fine to me. Properly supporting lots of real-world applications using MediaStreamTrack on Window would seem better to me. -- GitHub Notification of comment by guidou Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/113#issuecomment-2536282423 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:16:06 UTC