Relationship between transport maxIncomingBitrate and simulcast encoding maxBitrate?

mediasoup libraries
1

Apologies if this is more of a generalized RTC question which I know you do not want here. But I am a little unsure where the line is here with RTC parameters vs. mediasoup API methods. Anyway, reading through the mediasoup-demo I saw on the client:

const WEBCAM_SIMULCAST_ENCODINGS =
[
	{ scaleResolutionDownBy: 4, maxBitrate: 500000 },
	{ scaleResolutionDownBy: 2, maxBitrate: 1000000 },
	{ scaleResolutionDownBy: 1, maxBitrate: 5000000 }
];

And on the server config:

... (transport config options)
// Additional options that are not part of WebRtcTransportOptions.
maxIncomingBitrate              : 1500000

And when creating the transport:

// If set, apply max incoming bitrate limit.
if (maxIncomingBitrate)
{
    try { await transport.setMaxIncomingBitrate(maxIncomingBitrate); }
    catch (error) {}
}

My question is generally, how the maxBitrate settings for a spatial layers interact with the max incoming bitrate of a transport. And since simulcast sends data for each spatial layer, does this impact how many spatial layers actually get sent by the producer?

In the above example, the combination of all 3 spatial layer bitrates would exceed the max incoming bitrate, so are only the 2 lowest layers actually sent? Would the highest layer ever get sent since individually it exceeds the max incoming bitrate?

Would it be ideal to set a max incoming bitrate which is large enough to account for all spatial layers? So for the example above, a value of 6500000?

My hunch is that as usual I am misunderstanding what these maxBitrate values actually mean for the spatial layer encodings. Are these actually just hints for the consumer to select an appropriate spatial layer based on BWE and not really considered by the producer transport at all? I think the question still remains, if I send more spatial layers than can be accommodated by the max incoming bitrate, how are they selected?

2

transport.setMaxIncomingBitrate(bitrate) uses REMB feedbacks (if supported by the client) to limit the total maximum bitrate that the client can sends over this transport, that’s all. The client should accommodate to it. How does libwebrtc/Chrome do it is up to libwebrtc, but basically it will decrease the bitrate of all simulcast encodings to honor the maximum bitrate.