Hi webdongel. Your question confuses me a little. OpenVidu lets you totally customize which users will publish a stream and which users will subscribe to which specifc stream(s).
If you want that every user pusblishes their own stream and subscribe to all of other published streams, you do that. If you want certain users to not publish and only subscribe, then you do that. If you want some users to publish for a while and then not publish, you do that. If you want some users to subscribe to a stream for a while and then stop receiving that stream, you do that.
So does each user really need the publisher Role? No. Only if they need to publish they need publisher role.
The user role “SUBSCRIBER”, “PUBLISHER” and “MODERATOR” just protects in the server side the ability of users to “subscribe”," publish" or “manage other users streams”. A user with role SUBSCRIBE will never be able to publish a stream even in the case they are hackers and hack your app in the browser to undesirely call the publish operation.
I am worried about performance and speech quality if really each user will have the publisher role!?!!!
So don’t do it. If your OpenVidu Session has only 1 publisher and 20 subscribers, then the session has 1+20 = 21 streams. If your 20 users are all publishing and subscribing to all streams, your session has 20*20= 400 streams. Your application should do what you want it to do.
Of course if you are talking specifically about current status of OpenVidu Call application, then yes, by default this application gives all users PUBLISHER role. We are working right now in an improved version of the OPenVidu Call app to give it a backend side in Node to allow server-side control for this kind of things, including different roles for users.
Stay tuned for the new version of OpenVidu Call coming very soon.
20 users scenario: 400 strems are so crazy. Because one school class have 29 students and one teacher so in total 30 users.
30 users with video and audio makes 30x30 >> 900 streams for only one class
so if we have 20 classes we would have 20 x 900 streams = 18.000 streams for only one school, thats not possible for any school to pay an amount for a server who have that much cores
So I am really wondering, how other software handle these problem (zoom, jitsi etc.)
But we don’t (can’t) want to use these tools because they are outside of Germany hosted and because of GDPR and data policy things, we had the great idea to develop our own app.
but the AWS isntance and also hosting own server will be soooooo expensive that no school will purchase this service from us.
Well, that’s just simple math. In a 30-person classroom, each student would need to send their video stream and receive 29 streams. Multiply x30, that is 900 streams in total in the server, yes. And that’s not all: for each user to render 30 real-time video streams in their browser is not easy at all. Modern browsers are powerful tools, but they can suffer if they need to process 30 different videos at the same time.
This is like this in OpenVidu or in any other existing videoconference technology. So how do people deal with this? Easy: not implementing a 30-to-30 classroom where everybody can see everybody else all the time. All “online classroom” services or platforms you will find usually let the teacher publish the stream and everybody else receive it, but students usually only can publish one by one along the teacher or other students. To sum up: reduce the number of published streams at the same time.
A use case we’ve been helping made the teacher the only user receiving all other streams at the same time, but students would all publish a 1fps or 2fps video stream at most, so the server, client and teacher’s bandwidth didn’t suffer that much.
Real time video conferencing is hard, as you can see. We hope OpenVidu makes at least the development part easier than having to implement all of it from scratch.
Since my use case is quite close to this, I want to clarify. I have say 15 participants but only one is publishing at the same time. They switch every 30 seconds. So publisher #1 is publishing for 30 seconds, then publisher #2 and so on. Never all at the same time.
My approach to this is to connect all-to-all (so I have 15*15=225 streams) and disable tracks for all others participants, except one who is publishing right now. I think this is what you referenced on when saying “1-2 fps at most” (I’m thinking you mean that when media track is disabled, it works at this super low fps).
Is it correct implementation? Is any way I can optimize it so I actually have only 15 streams, not 225? Important that we can’t introduce any delays during switching publishers.