- From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Oct 2024 16:13:54 +0000
- To: public-webrtc-logs@w3.org
Let me try to clarify this after cappucino and water with hbos: * In the *past* sCP required the codec to be in send **and** recv. This was a problem for receive-only codecs (which exist in the wild) * sCP *currently* requires the codec to be in the recv capabilities * *Future* sCP will allow the codec to be in send **or** recv capabilities. This *allows* a sender to change the *codec order* on a sendonly transceiver too (since the remote will match by default) which seems useful. Since we lack a sendonly codec this is not testable in WPT *currently*. * Minor ergonomics issue: the input to sCP should probably come from `RTCRtpTransceiver.getCapabilities(kind)` for consistency with how sCP operates on the transceiver? That part is 👍 I do not see a need to change those rules based on direction so disagree with the second code block of [this comment](https://github.com/w3c/webrtc-pc/issues/3006#issuecomment-2390771213) but that might have been overtaken by events? I **question** the conclusion to do "Proposal A" of the slide above. The Working Group seems to make decisions based on opinions while lacking tests which, like [this fiddle](https://jsfiddle.net/fippo/nvjx1r98/) (took five minutes to write... for the second time, I had shown this in February already) which shows that "deployed code" is doing proposal C. Transceivers can get stopped for a number of reasons, applications *must* check what was negotiated anyway. -- GitHub Notification of comment by fippo Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/3006#issuecomment-2447683102 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 30 October 2024 16:13:55 UTC