- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Fri, 17 Nov 2023 10:18:58 +0000
- To: public-webrtc-logs@w3.org
> We shouldn't repeat the mistake of putting codecs on transceivers, as sender and receiver codec-needs may differ. If the problem is not forcing bi-directionality, then it sounds like there are three options? 1. Putting it in the `transform`. 2. Putting it on the `sender` and `receiver`. 3. Adding a `direction` argument for the `transceiver` method. Codec preferences are already decided on the `transceiver` and we now have `sender.setParameters()` with ability to specify `codec`. So codecs and negotiation are already firmly within the transciever/sender/receiver realm, regardless of where to place the "add codec" method/argument. The transceiver needs to know because of `setCodecPreferences` and the sender needs to know because of `setParameters`. Pros/cons of each approach? @jan-ivar @alvestrand -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/pull/186#issuecomment-1816099254 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 17 November 2023 10:19:00 UTC