Re: [webrtc-pc] What is setCodecPreferences's contract? (#2845)

> Our concern is that the API allows hardcoded inputs, which if it becomes a prevalent pattern causes implementation-dependent failures, and web compat headaches for non-dominant browsers in particular.

 I don't think hardcoded inputs would work well for applications or most codecs, except maybe for VP8. Most other codecs have FMTP parameters and make them too inconvenient to hardcode in most applications, since those may vary depending on the platform or HW support. While it's a risk, I believe it to be low as it is a lot harder to hardcode values than to do something like:
```
transceiver.setCodecPreferences(findCodecs(getCapabilities('video').codecs, ['VP9', 'H264']));
```

> But it's not clear from the PR whether we are:
> - Cementing codec comparison to ALWAYS be by clockRate, mimeType, channels and sdpFmtpLine, and no future members, or
> - We intend to extend the comparison algorithm in the future to include future members.

I believe we should probably match what I would call _keyable_ fields of the dictionaries, which are now located in `RTCRtpCodec` and uniquely identify a codec that would result in the `a=rtpmap` entries in SDP.

For example, should be have kept `scalabilityModes` from WEBRTC-SVC as an extension to `RTCRtpCodecCapability`, I believe that we may not find it relevant to check the array values as they are a property of a codec but don't uniquely identify one.
In this regard, I believe we could change `setCodecPreferences()` to maybe take a `sequence<RTCRtpCodec>` instead.

In any case, any future change would have to be backwards compatible with current observed usage of the API. Considering that even adding a field changes the iteration order, which is guaranteed by WebIDL, even that could break applications. While we can't be certain of never ever breaking any application, we can only do our best to avoid it, and we're never at risk that some application relies on some probably unreasonable parts of our exposed API.

> If it's 2, don't we risk breaking existing sites? Also, if it's 2, we can simplify the algorithm to compare ALL members so we don't need to update it in the future.

If you can provide me with language doing this, I could integrate it in the PR, otherwise we could update the algorithm whenever we need to. It's simple enough as it is.

-- 
GitHub Notification of comment by Orphis
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2845#issuecomment-1488756131 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 29 March 2023 14:40:35 UTC