- From: docfaraday via GitHub <sysbot+gh@w3.org>
- Date: Fri, 23 Aug 2024 16:51:43 +0000
- To: public-webrtc-logs@w3.org
> > ... fmtp in the capabilities differs even slightly from what the remote puts in its SDP, we won't try to honor that .codec setting because it doesn't match. > > I don't believe the spec says what to do here. The codec dictionary algorithm is only used to validate JS inputs AFAICT. > > All it says about it seems inferred [here](https://w3c.github.io/webrtc-pc/#dom-rtcrtpencodingparameters-codec): _"Optional value selecting which codec is used for this encoding's RTP stream. If absent, the user agent can chose to use any negotiated codec."_ Well, that's a separate (and easier) bug. Right now, the wpt expects setting .codec based on getCapabilities, and then negotiating, will cause that codec to be used if it matches the remote SDP. There's no explicit prose around doing this in the spec right now, but it definitely seems to be the intent. The wpt also expects .codec to be automatically unset if the remote SDP does not contain a match (there's definitely nothing in the spec about this). Also, there's the |choosableCodecs| stuff in setParameters now that has .codec being compared to: 1. The negotiated codecs, if set 2. The codecs configured with setCodecPreferences, if set 3. The codecs in getCapabilities, if all else fails This strongly suggests that it is "normal" to be setting .codec based on getCapabilities, which I suppose is why we see the wpt using this pattern. -- GitHub Notification of comment by docfaraday Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2987#issuecomment-2307457810 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 23 August 2024 16:51:44 UTC