- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 16 Nov 2023 19:09:01 +0000
- To: public-webrtc-logs@w3.org
I'm glad my feedback led to a reduction in methods, but this still adds a codec API on _transceiver_ instead of on the _transform_ as I proposed, so it doesn't yet satisfy my objections to this API in https://github.com/w3c/webrtc-encoded-transform/pull/186#discussion_r1361233157. We shouldn't repeat the mistake of putting codecs on transceivers, as sender and receiver codec-needs may differ. E.g. an app might encrypt on sending in one direction but not the other, i.e. have `transceiver.sender.transform` but no `transceiver.receiver.transform`, or use a different codec/transform the other direction. We don't want to get locked into negotiating both sending and reception of both. What codec the O/A needs to negotiate depends directly on the transform added, making it an inherent property of that transform. Separate methods the application needs to keep in sync seem like a mistake. Rebasing my advice, instead of: ```js transceiver.addCodec(codec, codec.packetizationMode); transceiver.sender.transform = new RTCRtpScriptTransform(worker, {}); ``` ...I think we should do: ```js sender.transform = new RTCRtpScriptTransform(worker, {codecs: [codec]}); ``` The UA then negotiates what's needed from that, like it does for `addTransceiver` and `createDataChannel`. The convenience method `pc.addCodecCapability` seems undesirable and redundant. We can have a sub-discussion about where `packetizationMode` goes, but I see taking two codec arguments back to back already caused confusion [above](https://github.com/w3c/webrtc-encoded-transform/pull/186#discussion_r1392669788), so I maintain my earlier advice of declaring the packetizing mode inside the made-up codec. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/pull/186#issuecomment-1815151172 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 16 November 2023 19:09:03 UTC