- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Dec 2022 00:40:37 +0000
- To: public-webrtc-logs@w3.org
> setParameters is the wrong mindset. setCodecPreferences is more similar.
Sure, let's use that. My point the same: set requires output from get as input, i.e. no hardcoded inputs, modulo https://github.com/w3c/webrtc-pc/issues/2805. For [example](https://jsfiddle.net/jib1/zu36q2d8/):
```js
const {codecs} = RTCRtpSender.getCapabilities("video");
codecs.sort((a, b) => b.mimeType.includes("H264") - a.mimeType.includes("H264"));
transceiver.setCodecPreferences(codecs);
```
Both setCodecPreferences and setParameters establish this get-before-set pattern, and setOfferedRtpHeaderExtensions violates it, because from what I can tell, this works:
```js
tc.setOfferedRtpHeaderExtensions([{uri: "urn:ietf:params:rtp-hdrext:ssrc-audio-level", direction: "stopped"}]);
```
This is what I think is bad and creates a web compat headache, because it's simpler to write code that breaks web compat that code that doesn't.
If you agree this wasn't the intent, which it sounds like you do if you're saying setCodecPreferences is the right model, then we can work to fix this.
I've already identified a couple of problems that need fixing to make this work more like setCodecPreferences:
1. structuredClone shouldn't be needed
2. partial arrays are a sign input isn't from get, and shouldn't be allowed
3. The algorithm doesn't weed out duplicates like setCodecPreferences does
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/130#issuecomment-1338493079 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 6 December 2022 00:40:38 UTC