- 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