- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Fri, 09 Feb 2024 09:13:44 +0000
- To: public-webrtc-logs@w3.org
Why would me saying which codecs I prefer to _receive_ make a `sendonly` transceiver not just incapable of sending, but make the transceiver permanently die? If this was "just receiver preferences", then `setCodecPreferences` would be a NO-OP. But it's not: ``` transciever.direction = 'sendrecv'; transceiver.setCodecPreferences([recvOnlyCodec]); O/A and everything works, other endpoint is asking for H264 transceiver.direction = 'sendonly'; O/A and transceiver is permanently stopped, other endpoint is not allowed to ask for H264 anymore ``` To safely change direction, the app needs to remember to clear their preferences or to always add dummy codecs just for the sake of having SOMETHING in the offer. Even if that something is not what the other endpoint is interested in. It's a footgun. Possible workaround: - Setting direction or codec preference in a way that results in an empty preference could throw. - Sensible defaults could be used. But I think whether we fail hard or patch this issue with workarounds, I think it's clear that receiver preferences ARE relevant for senders. JSEP does not allow not offering anything -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2936#issuecomment-1935571771 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 9 February 2024 09:13:47 UTC