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

> > Many things, like `addTrack` and `createDataChannel` affect what goes into SDP, so we should not limit ourselves in API design to put anything related to SDP on the transceiver.
>
> It's not a design mistake that neither addTrack() nor createDataChannel() are interfaces on Sender and Receiver.

My point is pc.addTrack() creates a sender, which can be assigned a transform or not. Only if it has a transform is there a need to specify input and output codecs. All else being equal, this suggests putting it on transform. If the user agent has what it needs to negotiate this then there's no need to further impact the API shape, is there?

As a mental experiment, imagine addTransceiver having an option to specify transform at time of creation of the sender:
```js
const transceiver = pc.addTransceiver("video", {transform});
```
This matches how sendEncodings can be specified at time of creation of the sender, which requires negotiation.

Negotiation predates transceiver, so transceiver is not special, nor the single housing point for APIs that affect SDP.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/pull/186#issuecomment-1877238570 using your GitHub account


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

Received on Thursday, 4 January 2024 15:01:16 UTC