openvidu
openvidu copied to clipboard
OpenVidu
Allow users to publish several streams at the same time
Allow users (connections) to publish several streams at the same time in the same session.
Hi @micaelgallego. Do you have any update on this? I'm thinking if I publish to 2 streams, let say one audio and one video, then if I change only video steam by camera or screen share. is there any possibility to encounter sync issue with audio and video? Do you have any better way to do this?
One user can publish several streams at the same time "hacking" openvidu-browser and creating two objects of OpenVidu class to simulate two users connecting at the same time from one user's browser.
In the future we plan to add this feature natively in openvidu-browser.
when I attempt to create two clients, one for a camera, one for a screen recording, the screen recording is always empty. So I guess a +1 from me on this feature.
Until the feature is implemented, you can use a hack creating two OpenVidu instances (one for camera and another one for screen share). We use it in OpenVidu Call application.
The hack is create two OpenVidu objects and simulate two participants in the same session.
It is in our roadmap, but we are working hard in other areas of the product.
I think having multiple publishers in single OpenVide instance is a good addition. +1 for this
@micaelgallego Could you link snippet or anything for this hack? I've been looking around and no luck.
You have to create several instances of OpenVidu object.
Every OpenVidu object can manage one publisher at a time.
Ok so after some digging I managed to find video-room.component.ts, which is basically openvidu-webrtc.service.ts which uses two completely separate OpenVidu objects like you say. Not sessions, not publishers, not users. This makes it extremely inefficient in terms of everything, but more importantly probably bandwidth use.
So I'm wondering how to get a PR started on this. If you can point me in the right direction where the root change needs to be to make it possible to have a shared session I can take this on.
Is this just OpenVidu or Kurento as well? How deep does the change need to be to get this working and where can I get started on it?
Well, it is not extremely inefficient. The only duplication is the web socket.
To allow reusing the same websocket connection between two publishers you will have to change openvidu-browser, openvidu-browser and possible the web socket protocol used to communicate between them.
It is not easy, for that reason is not already implemented.
The issue I have with it at the moment is the increased usage at server-side. Having a screen + video feed for every user cuts the number of users the sever can support by half, and the server does not scale at all. Would it help matters on the server-side + bandwidth if this enhancement is done? Would it be worth it if these two items are the only goal?
Also, this workaround makes composed recordings almost impossible, but they're very heavy to begin with.
Sending two streams with the same OpenVidu websocket connection wont make the server much more scalable.
The scalability bootle-neck is in the media. In any option (one or two websockets) the media sent (and received) will be the same.
This workaround has nothing to do with COMPOSED vs INDIVIDUAL recording. COMPOSED recording records all streams in a call togheter. INDIVIDUAL recording records every stream in its own file. Regardless how to manage websockets you will have the exact number of streams.
Hi there, just wondering if there is any news regarding this feature? Is the recommend solution for now to just use the "hack" suggested in the messages above? Or is there an alternative solution that might be coming somewhat soon?
We'd like to add this feature to our app (simultaneous webcam/screenshare) and we're debating whether we should pursue other features first (and wait for a potential non-hacky solution to this issue) or just implement this feature now using the method suggested above.
Thanks!
Hi @micaelgallego, not trying to hassle you or your team but it's been about 9 months since my last check in on this. As a paying enterprise user, it'd be nice if we could get some sort of timeline or update on this? Is OpenVidu still planning to add this feature natively to OpenVidu-browser?
I'm aware of the "hack" to implement this functionality but I'm not loving the idea of the putting in the dev work to implement that and then a few months later the native solution is released.
Thanks!
I understand this will be a useful feature to have. But, a we have a hack available, we are prioritizing other useful features.
Also, if you are using OpenVidu Components to build the UI, the hack is hidden to you.
The main issue is maintaining the API backwards compatible and simple enough.
We do not plan to implement the feature in the near future.
