Re: [webrtc-encoded-transform] Add description of an API for controlling SDP codec negotiation (#186)

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