- From: Florent Castelli via GitHub <sysbot+gh@w3.org>
- Date: Mon, 27 Mar 2023 11:41:12 +0000
- To: public-webrtc-logs@w3.org
Chrome does support `sdpFmtpLine` checks and you need to have a (loosely defined) match from values passed in `setCodecPreferences()` to the ones returned from `getCapabilities().codecs`. See: https://jsfiddle.net/e6z12na4/1/ Yes, those are dictionaries, you can create them out of thin air and (accidentally, or intentionally) match one of an implementation. It's meant to be a value semantics paradigm, and that's nothing new to developers. It's also probably too late to change those to platform objects as it will probably break existing code. While the specification is not as precise as it should, the intent of the related APIs has been clear to developers for a while and most are also probably using it correctly. By removing this part, we can get rid of most of your issues: > 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). And then we should just need to define a proper equality algorithm for codec objects, checking all fields from `RTCRtpCodec` just like current implementations are doing, which I said I'd be working on last Thursday. -- GitHub Notification of comment by Orphis Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2845#issuecomment-1484992256 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 27 March 2023 11:41:14 UTC