Update Specific RtpEncoding for Producer

mediasoup libraries
1

I was surprised to find producer.setRtpEncodingParameters(params) seems to replace the provided parameters in ALL encodings for that producer. Is there no way to update a specific encoding (i.e. by index), or add/delete specific encodings?

My use case: The app defaults to 2 encodings:

{ maxBitrate:  92000, scaleResolutionDownBy: 3 },
{ maxBitrate: 800000, scaleResolutionDownBy: 1 },

To avoid destroying & re-creating a producer, I’m currently using replaceTrack() to switch between userMedia and displayMedia (screenshare). When I switch to screenshare, I am setting maxBitrate very high or else it won’t work:

sfu_cameraVideoProducer.setRtpEncodingParameters({
maxBitrate: 9999999,
scaleResolutionDownBy: 1
});

I initially thought this was simply replacing the existing encodings with this one, but now realize it’s updating each parameter in ALL encodings. Which is fine, until the user switches back to userMedia, and then there’s no way to get back to a Simulcast encoding set…

Any thoughts/advice? Must I just re-create the producer from scratch?

2

The documentation explicitly says what it does:

Add parameters to all encodings in the RTCRtpSender of the producer. Use with caution.

On the other hand, there is the rtpSender property in Producer where you have direct access to the RTCRtpSender, which parameters you can set to your will.

In another order of things, Why don’t you simply have two separate producers for webcam and desktop sharing respectively in your app?

3

That’s indeed what the doc says.

You can also access producer.rtpSender directly. But you can not change number of encodings, the WebRTC API does not allow that. You can however set active:false in some of them.

4

Thank you both. I realize in hindsight that the instructions are explicit, but what can I say…I mis-interpreted! This is one of the only areas of the documentation that didn’t quite click for me, so perhaps a simple example could help others.

I did go ahead and create a separate producer for screensharing, which is working great. I don’t know why I was so adamantly trying to avoid that :grimacing: