please may I ask what would be a preferred setup for streaming WebRTC video from TD to 4 web clients (just over a local network)? Given the P2P nature of WebRTC I feel like there are basically two options:
Create 4 signalingClients in TD, each will connect to a single web client. Simple to setup, but heavy on encoding. Or am I missing something and there is a way to encode the video just once with such setup?
Use SFU (Selective Forwarding Unit) as a middle man. TD would be just a single client, encoding video just once. Sounds great, but how to go about signaling? I have looked at projects like mediasoup / jitsi / janus, but I guess each would require implementing TD’s signaling logic on their side. I am not sure how hard it could be, but I feel like it might take quite some time to get right.
Please do you think there are also some other / better options? Thanks.
If I follow what you are after, your TD side would need only one signaling client, if you run it all from one TD process.
Your web apps / devices would all be clients as well.
Using the signalingClient and signalingServer distributed with TD, and following the signalingAPI, you’d then proceed for your web app / web based devices to connect to TD, and TD would send 4 streams out.
Using a SFU, you do not need to implement TD’s signaling logic, you likely need to implement the signaling of the SFU. Consider TD a client in that case. If you take Jitsi, I assume you’ll have to send XMPP valid messages over WebSocket to announce yourself to Jitsi, and start an RTC call. Then you’ll work with all the signaling callbacks of the WebRTC DAT to finalize your signaling, and send your stream out using the Video Stream Out TOP.
The Web clients would then all connect to the SFU to receive that single TD stream.
Yes, I would like to run just one TD process. But even if I were to use a single signalingClient, I would still need to encode the video 4 times (for 4 separate streams), is that correct?
When I was experimenting with this setup on TD side (please see picture below) and WebRTC Web Demo on the other sides, I could always connect just from a single WebRTC Web Demo (as soon as I connected from one demo, other demo stopped receiving the signal with rotating banana).
Correct. This is just the way the demo is designed. It wasn’t intended to be used the way you describe it, so you have to hack it all to make it work as you want.
Please may I also ask if you have some preference in SFUs? I am not really sure how long it could take me to implement some other signaling into TD, but it seems like a cleanest choice at the moment (since without hw acceleration it is quite expensive to encode even a single stream). Please do you have some rough estimate on how long could it take to implement other signaling into TD (just trying to figure out whether I should dive into it or not).
We didn’t experiment much with any of the SFUs. All the SFUs listed above have good reputation and community as far as I am aware of. Your choice would likely end up being based on the tech stack they use. What language or protocols you are the most comfortable with, what features are important and supported by the SFU, etc.
I cannot give a rough estimate on how much time it’d take to implement but I assume that all the necessary callbacks are here on the WebRTC DAT and you’d mostly just have to route messages from your receiver / signaling client to the WebRTC DAT back and forth.
