- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Mon, 02 Dec 2024 20:35:48 +0000
- To: public-webrtc-logs@w3.org
>This is a common use case, Seems more common _not_ to have a "before" preview: None of the big sites with video effects have it. > ... and there are many others that require or prefer the track on window and don't need or want a track in the worker. Which websites require the "before" video on window? How do you know what they "prefer"? As #117 clarified, having a track tucked away in the worker using it is neither a burden nor a liability. It's quite clean: it lets the worker stops the source once piping ends. This cleanly reacts to downstream JS closing the "after" track, regardless of what thread it's on. > The current API shape forces a clone in such cases, which shouldn't be necessary. A "before" preview element is a separate sink with potentially separate concerns. Using clone to separate those concerns should be encouraged. For instance, tying their lifespans together seems like a mistake. In contrast, your alternative API seems flawed: 1. poor encapsulation: the worker has no way to stop the gUM track it's consuming 2. redundancy: the window has to manage two tracks, even when no "before" preview is needed 2. tight coupling: if the website forgets to clone its "before" track then stopping it stops the "after" track as well IOW leaving the window to manage the source discourages encapsulation and encourages repurposing without cloning, creating tight coupling that may surprise developers. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/116#issuecomment-2512762760 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 2 December 2024 20:35:49 UTC