Re: [webrtc-extensions] Add RTCRtpEncodedSource and explainer (#198)

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