Proposing setCodecPreferences to deal with both send and recv codecs about webrtc-pc

[fippo]

we must have something to offer

We don't. If we have nothing to offer this is similar to "we have nothing to answer" which is described as

None of the offered media formats are supported and, if applicable, allowed by codec preferences.

in https://rtcweb-wg.github.io/jsep/#rfc.section.5.3.1
I think this case is rare enough that going for 3 is a pragmatic solution. And yes, I have a code change for that already that is quite small

[aboba]

@henbos You may be taking JSEP Section 4.2.6 too literally. It is correct in saying that sCP is not for selecting what is sent. That is true regardless of direction. However, saying that sCP only applies to codecs that can be received, regardless of direction, has to contend with RFC 3264 Section 5.1:

"For a sendonly stream, the offer SHOULD indicate those formats the offerer is willing to send for this stream. For a recvonly stream, the offer SHOULD indicate those formats the offerer is willing to receive for this stream. For a sendrecv stream, the offer SHOULD indicate those codecs that the offerer is willing to send and receive with."

Since this is a SHOULD, there is some wiggle room for sendrecv streams. For example, a sendrecv m-line with preference {H.265, H.264} could be allowed if H.265 can be received but not sent. This would allow negotiation to succeed between a receive-only H.265 Offerer and an Answerer who can send and receive both H.265 and H.264, using only a single sendrecv m-line, as long as the Answerer included both H.265 and H.264 in its Answer. Since non-WebRTC endpoints may not support sendonly and recvonly m-lines, this approach has interoperability advantages.

However, concluding that sCP with a sendonly m-line is only about receiving preferences seems like a step too far. Instead I'd suggest that a sendonly transceiver can only offer codecs/profiles that can be sent (send-only or send/recv). In a situation where the browser can send at a different profile/levels than it can receive, only the send profiles can be included when direction = sendonly.

Similarly, a recvonly transceiver can only offer codecs/profiles that can be received (recv-only or send/recv). In a situation where the browser can send at a different profile/levels than it can receive, only the receive profiles are included. This is consistent with JSEP Section 4.2.6.

[aboba]

Related: aboba/hevc-webrtc#22

Justin's suggestion.

[dontcallmedom-bot]

This issue was discussed in WebRTC February 2024 meeting – 20 February 2024 (setCodecPreferences to deal with both send and recv codecs #2939)

[jan-ivar]

@henbos what are next steps here?

[aboba]

@jan-ivar H.265 is getting close to being enabled behind a flag, so in the near future we will be able to see how receive-only codecs behave, and what the problems are. At that point we can present the issue to the WG in light of the behavior we see. IMHO it would be desirable to converge on recommended changes prior to enabling H.265 by default.