mediaCodecs real life cofiguration

We have the following scenario:
1-2 Producers, thousands of Consumers.
Producers and Consumers could be anyone, mostly mobile (not specific browser/platform etc)
We deployed mediasoup on a cluster of machines and use remote routers to support all consumers.

My questions -

  1. In order to support as many users as possible, what would be the best configuration of the mediaCodecs used in the router (assuming we don’t have a re-encoder that can off-load the encoding from the producers and reduce the number of video key frame requests - setting keyFrameRequestDelay to 4 seconds)
  2. How much bandwidth should the producer have, when using this configuration?
  3. Any direction of to how can we implement a re-encoder that can provide multiple encodings and handle key frame requests?

Thanks,
EyalS

  1. VP8 → VP9 → H.264 will cover most devices needs except for few mobile devices. Opus for audio is generally accepted all around. Few cases where mobiles do not support these audio/video codecs or need a bit more help.

  2. I’d opt for anything around 120,000 - 500,000 (120KB/s->500KB/s) for regular streaming. If you’re doing screen share or wanting to see something clearer, that picks up around 900KB/s+. You could expect anywhere from 10->45MB/s overall usage at the server or monthly total of up to 100TB+ if it were full of peers streaming all day every day.

  3. Can’t suggest much, there may be some FFMPEG examples kicking around.

THANKS @BronzedBroth for the answer!
I’m trying to understand how it could work.
If we configure mediasoup to work with VP8, VP9 & H264, and as mediasoup is not re-encoding the streams, does it mean that we might get a scenario where during the negotiation the producer will work with 3 consumers, each with a different encoded stream? Meaning it would need to send and encode 3 streams to mediasoup (one for each encoding) X additional simulcast streams?
If this is the case, and if we don’t have a re-encoder in place, do you think it would be better to just use VP8?

You may want to read up on communication between client and server. It may explain this better:

As for strictly using VP8/OPUS; up to you it’s not overly a problem. To be safe though offer the support if its needed by the users.

Thanks, I actually read this.
Still wanted to verify.
If I’m configuring VP8, VP9 & H264, could it be that the producer will send all those 3 streams/encodings?

That’s up to you!
(mediasoup :: API)

Consider too:
Preferred spatial and temporal layer for simulcast or SVC media sources. If unset, the highest ones are selected.

Check out each codec and see their active support pros and cons.

I’m really trying to understand this. I don’t think it’s up to me ;(
If I’ll configure the 3 codecs and there are hundreds of consumers, it will most certainly be the case where the producer will need to send & encode 3 streams - is my assumption right?
(and on top of each stream the producrType configuration for each)

Generally speaking you can see the differences:

Normally vp8 is supported in most cases and has the better bandwidth/cpu performance.
VP9 uses less bandwidth but uses more CPU.
VP8/9 have low hardware support and drain more battery.
H264 uses more bandwidth but has hardware support in most devices, being more performant.

In most cases VP8 is the best option.

I’m afraid this will melt the producer device, the encoding CPU needed to encode in real time in all 3 encoders is almost impossible. E.g. imagine somebody is producing video from a tablet, you have CPU and bandwidth hog.

Doing re-encoding on the server side needs loads of work to allow scaling.

The following article is a good examples on the challanges of multi-codec support:

Hope it helps.

Are assuming that just because you setup 3 video codecs in the mediasoup Router it means that the client is gonna send its video using all them?

It is up to you,

You can tell any broadcasting user they must use VP8 and OPUS, or it’s their choice based on the options you provide them.

Consider avoiding any re-encoding if you intend for real time communication. If you intend to cache and store the data for later like a video file it could be of interest to process and make the video available in many formats. So the difference between a chat-room vs YouTube; if you want a chat-room you can skip all that unless you got specific features requiring.