How does producer performance scale compared to consumer performance?

mediasoup libraries
1

Hey Team,

In the scalability documentation, you mention how one worker can support ~400-600 consumers. You also mention how in a one-to-many application that one or few producers can be piped to different workers with pipeToRouter().

If I wanted to scale a many-to-many application by piping a substantial number of producers, how would that impact performance? Would they take about us much work as a consumer, meaning you can have 400-600 total producers and consumers, or would they scale differently?

Thanks!

1 Like
2

Not directly answering your question, but this is actually what will make scalability suffer, not necessarily the piping or redirecting the traffic:

When broadcasting a video stream to many viewers (hundreds or thousands of consumers) it’s important to be aware of how video RTP transmission typically works:

  • A viewer may eventually loose video packets so would request packet retransmission to mediasoup. Retranmissions are handled per transport (they do not reach the broadcaster endpoint) so there is no limitation here.
  • A viewer may connect or reconnect, or may change its preferred spatial layer, or may just loose too many packets. Any of those circumstances would imply a video key frame request by means of a RTCP PLI or FIR that reaches the broadcaster endpoint.
  • Upon receipt of a video PLI or FIR, the encoder in the broadcaster endpoint generates a video key frame which is a video packet much bigger than the usual ones.
  • If the encoder receives many PLIs or FIRs (although mediaoup protects the producer endpoint by preventing it from receiving more than one PLI or FIR per second) the sending bitrate of the broadcaster endpoint would increase by 2x or 3x. This may be a problem for the producer endpoint and also for viewers that will receive much more bits per second.
    • NOTE: This may be mitigated by increasing the default keyFrameRequestDelay value, although that would cause longer “black-video” periods.
  • And that is the problem.

In those scenarios, a “re-encoder” in server-side is required. This is, an endpoint that consumes the streams of the broadcaster endpoint, re-encodes those streams and re-produces them into a set of mediasoup routers with hundreds or thousands of consumers in total. Since such a “re-encoder” runs typically in the backend network, it’s not limited by available bandwidth.

At the end, those scenarios require a proper architecture with distribution of viewers across multiple mediasoup routers (in the same or different hosts) and special “re-encoder” endpoints in the backend that can absorb PLIs and FIRs generated by a subset of those viewers.