- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Dec 2022 16:54:21 +0000
- To: public-webrtc-logs@w3.org
> setParameters is different because it is more dynamic and harder to come up with valid input. I'd argue it's equally hard to come up with valid input to setCodecPreferences: - _"The codecs sequence passed into [setCodecPreferences](https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver-setcodecpreferences) can only contain codecs that are returned by [RTCRtpSender](https://w3c.github.io/webrtc-pc/#dom-rtcrtpsender).[getCapabilities](https://w3c.github.io/webrtc-pc/#dom-rtcrtpsender-getcapabilities)(kind) or [RTCRtpReceiver](https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver).[getCapabilities](https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver-getcapabilities)(kind), where kind is the kind of the [RTCRtpTransceiver](https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver) on which the method is called. Additionally, the [RTCRtpCodecCapability](https://w3c.github.io/webrtc-pc/#dom-rtcrtpcodeccapability) dictionary members cannot be modified. If codecs does not fulfill these requirements, the user agent MUST [throw](https://webidl.spec.whatwg.org/#dfn-throw) an [InvalidModificationError](https://webidl.spec.whatwg.org/#invalidmodificationerror)."_ See https://github.com/w3c/webrtc-pc/issues/2805 for details. > > partial arrays are a sign input isn't from get, and should be disallowed > > This model does not work for codec preferences, Thanks for pointing out setCodecPreferences accepts partial arrays, but the semantics are different from here. In setCodecPreferences, _"the [user agent](https://w3c.github.io/webrtc-pc/#dfn-user-agent) MUST use the indicated codecs, in the order specified in the codecs argument"_, which I interpret to mean MUST ONLY use the indicated codecs. IOW, leaving a codec out means: don't use it. Compare to [setOfferedRtpHeaderExtensions](https://w3c.github.io/webrtc-extensions/#dom-rtcrtptransceiver-setofferedrtpheaderextensions), where leaving out a header extension means: don't modify it and leave it as-is. This is the cherry-set pattern we abandoned years ago for setParameters, and is the pattern I fear invites hard-coding. This also seems confusing, especially since the names _seem_ to invoke the same semantics: set what must be used (and use no more). Would you be OK with treating each extension NOT in extlist as having the value `direction: "stopped"`? I think that would solve both this semantic inconsistency and my concern over hard-coded strings sufficiently. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/130#issuecomment-1339673901 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 16:54:22 UTC