I have read the documentation on my best senses and I still have 2 questions:
Consider a scenario where I have a single broadcaster broadcasting 2 streams containing a video track and an audio track, totaling 4 tracks. Then, which approach is better: should I create 2 different sendTransport and recvTransport, and send and receive the 1st stream on the 1st transport and the 2nd stream on the 2nd transport? Or should I just create a single transport for sending and receiving all 4 tracks, considering a broadcaster can mute any track on purpose?
From the client side, how can we create multiple producers like one for the audio track and one for the video track, and multiple consumers, one for the audio track and one for the video track, within the transport? Because when I have tracks, one for audio and one for video, all I can do is transport.produce({track}) for producing, and similarly for corresponding code for consuming the track. Does it automatically create the number of producer-consumers based on track count when we call transport.produce({track}) or transport.consume({track})
You need separate transports for sending and receiving. But one transport per direction is enough for multiple producers/consumers.
Start simple: just create by default one sending and one receiving transport for each of your clients, even if they are not sending/receiving anything. Then start producing/consuming as necessary. Since you already have the transports created by default on all your clients, you can stop thinking about the transports and focus on the consumer/producers.
Later, you can optimize your app to not create the transports that are not needed.
Okay, thank you. Could you please also guide me on how to decide if the worker is overloaded and dynamically create a new worker when it’s overloaded so that I can use a new one instead of the old one?
It depends of your use case or preference, there are several alternatives. Some people prefer to have a hard limit and once there’s a number of Consumers, they create a new Worker. That’s the solution provied in EduMeet, for example. Others like me prefer to squish the CPU and do it by checking the actual CPU usage, that’s more complex but also more optimized. That last one is the solution I’ve implemented on Mafalda SFU.