I am testing an application where I am creating only 1 receiver transport on client side, and using that 1 receiver transport to consume multiple streams being produced. So on client side there is only 1 receiver transport and on server side there are n transports where n is number of participants.
The things is by doing this way there is a video lag on all streams not a little but big one.
Then to find the cause of this I spent 2-3 days but couldn’t find anything then eventually I tried the other approach which is 1 receiver transport per stream. The results were amazing there was not lag in video streams I tested it for 2 hours, there was no issue.
So apparently it seems 1 receiver transport, which is a peer connection, doesn’t handle 10-20 streams very well, may be it is ok to have 4-5 streams but 10-20 were causing lots of issues.
This thing even happens on the demo mentioned in docs, because it is using 1 receiver on client side:
Can someone confirm that this is the case?
Why 1 receiver can’t handle 10-20 streams on client side? Theoretically one peer connection should handle this number of streams as there is no limit mentioned by webrtc.
I’ll tell you it’s much better to have many peer-connections opened, one for your broadcast and each person you view. This allows you to have n-amount of servers handling the users. I’d never favor a single connection or that way of thinking as if one server goes down there goes the whole nest.
As for 10-20 streams, we’re talking higher demands that could be high for CPU/bandwidth; surely watch that as the worker uses a single core (or parts of it) so you could be maxing out the core/worker.
Depends on architecture. It is generally much better to have one connection, so you can benefit from meaningful priorities between different streams in case there is a congestion.
One connection or many, it all goes through the same client network interface, so there shouldn’t be much difference. This sounds more like an artifitial limitation on the number of packets per UDP port somewhere.
n-amount of servers? I mean whether I open 1 receiver per client of 1 receiver per stream they will be on a single worker in most cases in a single call. Also cpu/core usage is not an issue at my side as I have very high end server and cpu mostly stays at 1% with 15 participants. Something else is causing the issue.
Theoretically this seems right to me but somehow streams get disturbed when there is 1 receiver per client but works well if there is 1 receiver per stream. May be the point @snnz mentioned about limitations on number of packets per UDP port is the issue, what do you say?
You can test it on the mediasoup3 demo with around 10-15 people you will see the issue.
Also cpu/core usage is not an issue at my side as I have very high end server and cpu mostly stays at 1% with 15 participants. Something else is causing the issue.
If you think so, sure. Must be better than all of our servers. Double check your results.
I am answering here to my own question:
After experimenting on it for around a week the final conclusion is that using 1 receiver transport per client causes video lag and after few minutes leads to streams being ended especially on average network and by average I mean 10-15 mbps.
The solution is to use 1 receiver transport per stream or 1 receiver transport for 2-5 streams may be e.g I use 1 receiver transport per remote person in call, 1 remote person’s camera stream and screen stream both are consumed on that 1 receiver transport. This gives best results.
These are the configuration on which I tested all of this:
