Re: [webrtc-pc] setCodecPreferences vs unidirectional codecs (#2888)

The _order_ in the codec list is purely a receive preference that can be ignored.

But the set of codecs - which ones are present in the negotiation - does affect what is allowed to be sent and/or received. You can't send something that doesn't have a PT or which the other side does not recognize.

The sentence that says `If the intersection between codecs...` is not intended to go against JSEP, I remember adding it as a protection against shooting yourself in the foot where one of the directions has an empty set of codecs. But if we want to support unidirectional codecs, which I think we do, then this sentence should be deleted or modified.

You can always get around it by adding another codec to the list as a dummy codec ensuring that there always is something that could be used for sending or receiving, but that is a bad API design when we want to support uni-direction.

Fixing this would not be a backwards compat issue since it would only expand the set of possibilities beyond what they are today.

-- 
GitHub Notification of comment by henbos
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2888#issuecomment-1822269060 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 22 November 2023 07:52:51 UTC