- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 Mar 2024 17:40:59 +0000
- To: public-webrtc-logs@w3.org
I would summarise my concern as: * The potential redundancy and the extra latency a frame-based API has compared with a potential packet-based API My other non blocking comment is API shape (keeping the feature set as it is, meaning let's keep it to dedicated worker in this version): * Evaluate transfer-based vs. script-transform-like API As I commented on https://github.com/w3c/webrtc-encoded-transform/issues/211#issuecomment-1844972816, there are two different API proposals. The first one is well described in the explainer. The second is a script transform like API, something like: ``` [Exposed=Window] interface RTCRtpSenderEncodedSource { constructor(Worker worker, optional any options, optional sequence<object> transfer) }; [Exposed=DedicatedWorker] interface RTCRtpSenderEncodedSourceController { WritableStream writable; // Or enqueue method. // Need congestion API, error API and enqueue API }; partial interface DedicatedWorkerGlobalScope { attribute EventHandler onrtcencodedsource; } ``` From a user perspective, there is probably no difference. There are probably some differences in terms of future-proofness, ease of use, ease of spec/dev... -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/pull/198#issuecomment-2004552007 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 18 March 2024 17:41:00 UTC