Hi - I was wondering if there are any strategies for speeding up consumption if you’re trying to have the client consume many tracks (~20) at the same time.
I understand that the async queue is going to make it so that to some extent the speed is going to speed_of_consuming_one_track * number_of_tracks (since all tracks are on the same transport). Other than creating multiple receive transports, are there any other strategies on the client side to be able to consume many new tracks rapidly?
Thank you for the help and for the awesome library + documentation.
I get your point but creating many consumers at once would be problematic. Imagine that the call to setRemoteDescription() fails, it would be impossible to know which exact consumer info made it fail and it would be impossible to make the others work.
Said that, even if done one by one it’s really fast and shouldn’t be a problem.
Right - this makes sense. I assumed that was the reasoning… I was just wondering if there was anyway I could change things to make one call to setRemoteDescription() since I know the 20 tracks ahead of time. Anyhow, I think you’re right that it should be fast enough that one by one it isn’t really a problem. In my implementation it takes about ~50ms to consume a single track using Chrome on a mac but 20 tracks ends up taking quite a bit longer than 1s (closer to 2) - so that is likely some implementation errors that I will hunt down. Even 2s is totally fine though… Part of the reason I was looking into tricks to speed things up is because on my Windows computer (using same version of chrome on same network) subscription of a single track is closer to 150ms. Going through the debug logs that mediasoup-client outputs, it seems like it is slower across the board (no single function obviously taking more time). The sdp offers look identical so I’m not sure where to look to see what’s causing the slowness on Windows. I’ve seen from prior posts that you don’t have a use a Windows client … but do you have any guesses / techniques I might use to debug this speed change further? I’ll post here as a follow up if I do discover something (as it is most probable this is some simple user error, but thus far my debugging hasn’t given me any good ideas).
I’m afraid I don’t know how to help. It’s unclear whether such a delay happens due to calling setRemoteDescription() one by one (for each Consumer) or whether the same would happen if a single setRemoteDescription() call is invoked with a SDP representing the info of all Consumers.
I’m using one transport - but switching to many obviously increases the speed to some extent. No worries - thanks for taking a look! I’ll update here if I encounter anything that might be useful to others related to this inquiry.
Hmmm, never thought about it like that Only places I think you could really harness a bit more speed from is utilizing For loops, removing any Map structure and using simple Arrays/Objects.
As for consuming broadcasts, that’s handled per user basis, and even with one camera loading in there’s the needed time to buffer/load the camera for the client.
Which leads me to, trick your client?
If on loading of a room, you get a userlist of 120 users, and 50 broadcasters; perform your loop and allow each of the broadcasters but while allowing them create their video elements ahead of time with their names and all sorts. In milliseconds the entire screen will fill and followed by will be the broadcasts you just consumed however no matter what this will take some time.
Advanced and genuinely overkill, you could run Workers… Beyond this you can only really take them on one by one and by huge-lists. The natural process of RTC’s awaits will make you wait so do everything you can ahead of time before that gets started and on room join this is acceptable when everyone is loading.