Re: [rtcweb] JSEPbis: Questions about send-only/recv-only codecs and Section 4.2.6

[Roman Shpount <[e-mail]>]

I think the main confusion here is that all preferences are defined for all
"m=" line directions.

For sendonly, setCodecPreferences should define what codecs are preferred
to send and should only include codecs
from RTCRtpSender.getCapabilities(kind).

For recvonly, setCodecPreferences should define what codecs are preferred
to receive and should only include codecs
from RTCRtpReceiver.getCapabilities(kind).

For sendrecv,  setCodecPreferences should define what codecs are preferred
to both send and receive and should only include codecs which a present in
both  RTCRtpSender.getCapabilities(kind)
and RTCRtpReceiver.getCapabilities(kind).

The last one is the most problematic since it conflicts with the current
use cases.
_____________
Roman Shpount


On Sat, Mar 2, 2024 at 11:14 AM Bernard Aboba <[e-mail]>
wrote:

> The text in WebRTC-PC also includes statements about sCP() that do not
> seem to apply to the send-only case. For example, in Section 5.4:
>
> *setCodecPreferences
> <https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver-setcodecpreferences> will
> reject attempts to set codecs not matching
> <https://w3c.github.io/webrtc-pc/#dfn-codec-match> codecs found
> in RTCRtpReceiver
> <https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver>.getCapabilities
> <https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver-getcapabilities>(kind),
> where kind is the kind of the RTCRtpTransceiver
> <https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver>** on which the
> method is called*.
>
> For a send-only m-line, does sCP really require a match to codecs found in
> RTCRtpReceiver.getCapabilities(kind), or should it use
> RTCRtpSender.getCapabilities(kind)?
>
> On Sat, Mar 2, 2024 at 4:29 AM Harald Alvestrand <[e-mail]> wrote:
>
>> Attempting to reflect my current understanding:
>>
>> The only way I can interpret the current text in a sensible manner is to
>> focus on the word "directly" - given that the text on processing the
>> preference list also says that if the responder has no preference, the
>> codecs in the sendonly media section's preference list should be
>> interpreted as "the codecs that the offerer wishes that the responder
>> should respond with as their preference, if they can receive them".
>>
>> This *indirectly* influences the choice of codecs, since the receiver's
>> response will limit the sender's selection of what to send.
>>
>>
>>
>>
>> On Fri, Mar 1, 2024 at 9:00 PM Bernard Aboba <[e-mail]>
>> wrote:
>>
>>> The purpose of this email is to alert the RTCWEB WG to a potential issue
>>> that has been pointed out in JSEPbis Section 4.2.6, with respect to the
>>> operation of setCodecPreferences().
>>>
>>> Currently, support for the H.265 codec in WebRTC is underway in multiple
>>> browsers, including Chrome, Firefox and Safari.  Safari Tech Preview 189
>>> has enabled by default support for both sending and receiving H.265, while
>>> Chrome and Firefox are working on enabling reception of H.265.  This has
>>> lead to discussion of potential interoperability issues between browsers
>>> that can Offer H.265 on a send/recv m-line, and browsers that can only
>>> Offer H.265 on a recv-only m-line.
>>>
>>> At the AVTCORE WG Virtual Interim on February 13, 2024, we
>>> discussed Issue 22 relating to the handling of send-only and recv-only
>>> codecs:
>>> https://github.com/aboba/hevc-webrtc/issues/22
>>>
>>> draft-uberti-rtcweb-rfc8829bis Section 4.2.6 says:
>>>
>>> "The setCodecPreferences method sets the codec preferences of a
>>> transceiver, which in turn affect the presence and order of codecs of the
>>> associated "m=" section on future calls to createOffer and createAnswer.  *Note
>>> that setCodecPreferences does not directly affect which codec the
>>> implementation decides to send. It only affects which codecs the
>>> implementation indicates that it prefers to receive, via the offer or
>>> answer.*  Even when a codec is excluded by setCodecPreferences, it
>>> still may be used to send until the next offer/answer exchange discards it.
>>> "
>>>
>>> Questions arose relating to the (red) text in italics, because it does
>>> not appear to be consistent with the definition of setCodecPreferences()
>>> within the WebRTC-PC API specification. In particular, while the text may
>>> be correct with respect to operation of sCP() on a send/recv or recv-only
>>> m-line, for a send-only m-line it seems odd to insist that sCP() will only
>>> affect receive preferences, not send preferences.
>>>
>>> Currently within the W3C WEBRTC WG, several issues have been opened
>>> relating to the behavior of setCodecPreferences():
>>>
>>>    -
>>>
>>>    w3c/webrtc-pc#2936 <https://github.com/w3c/webrtc-pc/issues/2936>
>>>    -
>>>
>>>    w3c/webrtc-pc#2933 <https://github.com/w3c/webrtc-pc/issues/2933>
>>>    -
>>>
>>>    w3c/webrtc-pc#2935 <https://github.com/w3c/webrtc-pc/pull/2935>
>>>    -
>>>
>>>    w3c/webrtc-pc/#2888 <https://github.com/w3c/webrtc-pc/issues/2888>
>>>
>>> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>