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 position about this is that a frame-based API and a packet-based API offer different tradeoffs and therefore support different use cases.
For use cases where the decision is based on frame properties, the extra latency of the frame-based API is not a problem since you have to wait for the whole frame to make the decision. For the glitch-free failover case (a.k.a. fan-in) it is also good because it provides an ergonomic mechanism that increases reliability without introducing timeouts (other than the latency of waiting for a frame). 
Also, an important practical consideration is that we have production-tested building blocks that make it easy to deploy a frame-based API, whereas a packet-based API is still in early stages of discussion with challenges that may still be unknown. 


>   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 [w3c/webrtc-encoded-transform#211 (comment)](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...

Something I like about this alternative shape is the consistency with webrc-encoded-transform, which will give us the opportunity to evolve both APIs in a similar manner. For example, we can define the congestion API in the same manner for both.  Also, it also addresses your concern about transferability.
I'm fine with proceeding with this shape if you  and @jan-ivar are also OK with it.


-- 
GitHub Notification of comment by guidou
Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/pull/198#issuecomment-2009454722 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 20 March 2024 12:29:12 UTC