Re: [webrtc-extensions] Potential web compat issue with setOfferedRtpHeaderExtensions (#130)

setParameters is different because it is more dynamic and harder to come up with valid input.
It goes overboard even, why do you need to know what the other side negotiated if all you wanted to do is to set a maximum bitrate?

There is no hard set-before-get pattern for setCodecPreferences because the source and target are different objects - in one case the static RTCRtpSender.getCapabilities, in the other the peerconnection.
You can ask setCodecPreferences to only do VP8 or H264 CBP (which will implicitly work because those are MTI).

For setOfferedHeaderExtensions you could even use RTCRtpSender.getCapabilities('video').headerExtensions as input. However, that does not show header extensions that are not enabled by default, i.e. stopped.
Again, that is a valid model. We still need headerExtensionsToOffer because we can include non-default extensions there.

> partial arrays are a sign input isn't from get, and should be disallowed

This model does not work for codec preferences, they have no `direction` (as currently implemented; I would actually like it to have one but... backward compat). I  actually prefer using [].filter to the "set to stopped" method stipulated by setOfferedRtpHeaderExtensions. Both methods work however.

Please keep in mind that the pretense that RTCPeerConnection is used by "web developers" is a myth.

-- 
GitHub Notification of comment by fippo
Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/130#issuecomment-1338962429 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 08:33:05 UTC