Explicitly setting a non-default codec when creating producer in libmediasoupclient

I can’t create two video producers with different codecs on same SendTransport using up-to-date libmediasoupclient version (from m112 branch).

Our media server declares both h264 and vp8 codecs as supported (both of them are listed in router RTP capabilities). After initialising and loading a mediasoup client device, I can also see both of them in device’s RTP capabilities. We have some custom logic on the client side for selecting producer codec, just like this document suggests.

When creating a producer, we pass desired codec as codec parameter to SendTransport. That approach works on JS client as expected. But on the native client (iOS, using the libmediasoupclient) the codec parameter doesn’t work. After digging into the implementation, I’ve found that selecting a non-default codec is not assumed by underlying code.

Here is a simplified trace that shows the error (as I see it):

1. Send transport creation
Application level code
Device::CreateSendTransport(...)
SendTransport::SendTransport(...)
ortc::getSendingRtpParameters(...) / getSendingRemoteRtpParameters(...)

2. Producer creation
Application level code
SendTransport::Produce(..., codec, ...)
SendHandler::Send(..., codec)
ortc::reduceCodecs(..., codec);

On the first step, inside getSendingRtpParameters(...) / getSendingRemoteRtpParameters(...) methods we have a break in loop over codecs after finding the first codec with given media kind. There is also a comment stating “We assume a single media codec plus an optional RTX codec.”. So after the first step SendHandler only has one supported codec per media kind.

On the second step we pass the codec parameter from application level down to reduceCodecs(...) method, which will search in array always containing only one codec.

If I remove the break statement from getSendingRtpParameters(...) / getSendingRemoteRtpParameters(...) methods, producer codec selection begins to work. So I want to known if it’s safe and what was the original intention to limit this codecs array in SendHandler? Shouldn’t we have all the supported codecs now as there is the codec parameter in producer creation method?

This looks like a bug in the code. If you feel brave write a PR please. Otherwise fill and issue in GH. In both cases ensure (or highlight) that the code in libmediasoupclient matches (or must match) the corresponding code in mediasoup-client, please.

1 Like

Sorry for a delay. I’ve posted an issue and related pull request on github.