Hi,
I'm currently working on a video stream conference application that supports a simple MESH solution and then scales to a SFU after X participants.
I've been fooling around with Janus gateway API and tested different solutions for adding, removing or replacing video tracks and got it working very well. (Im not using Janus.js, instead i've built my own.)
So far i manage to come up with two solutions.
The first solution i've used is when a publisher wants to add/remove/replace a video track, they just publish to another handle and then signal the other participants that they should subscribe to that feed instead.
This works very well and i've had 0 problems with it, it even works with simulcast. But this is kind of an ugly solution in my mid because if i we are 4 publishers in the room and i have a max publisher limit of for example 4, and i try to do the above - it will fail. Even if i reverse the flow and destroy the published stream before publishing the new one - it doesn't switch seamlessly.
The second solution i've recently starting using is renegotiation to add/remove/replace a video track, and i've manage to get it working and it switches seamlessly. This is exactly the solution i'm looking for, but the problem is that i can't get simulcast to work with it. As stated in the first solution, simulcasting works perfectly but not in my second solution.
Clarification, in the second solution:
With simulcast enabled subscribers manage to receive the stream as normal, but 1-3 seconds later the video becomes very choppy, corrupt and unwatchable (its extremely unstable and doesn't work).
Even when i try to configure the temporal and substream parameters or changing the bitrate for publisher - yields me with the same result.
Information:
- Janus Gateway
- Plugin
- Webbrowser
- RTCPeerConnection
- createOffer
- iceRestart
- true = FAILS
- false = WORKS
- Simulcast
Janus Gateway API for renegotiation:
- Configure
- refresh (deprecated?)
- restart
- update
I've tried them all.
Sidenotes:
It seems to get stuck on "Negotiation update, checking what changed..." when doing the second solution. But it still works, subscribers get the stream regardless (w/ or w/o simulcast).
Regarding ice restart, i've come to understand that there is a difference between renegotiation and ice restart as stated in the documentation. But it should still work right? If ice restart is true, the RTCPeerConnection connects but after 10 sec it fails. (does it have to do with close_pc parameter maybe?)
When further investigating using solution two, if publisher add a video track, renegotiate and then a new participant joins the room, the new participant/subscriber doesn't receive a working video track. Very strange. (Could be an application problem, can skip this one if it doesn't make sense)
My question is really simple. Is there someone who have this this problem or a better solution?
Thank you