4 ms·
In practice this is what SFUs are for. You would simulcast a set of different encodings from OBS to the SFU and that would fan out to other SFUs and clients as
by fidotron 3y ago
In practice this is what SFUs are for. You would simulcast a set of different encodings from OBS to the SFU and that would fan out to other SFUs and clients as appropriate until the desired scale is reached. This does get expensive.
If you don’t actually need the low latency then you are better off with hls-ll delivered via a CDN.
- EGreg 3y agoIf I'm ingesting and decrypting the stream anyway, wouldn't it be better to build an MCU, to send out one stream and adapt the resolution for each client? https://www.digitalsamba.com/blog/p2p-sfu-and-mcu-webrtc-architectures-explained https://www.digitalsamba.com/blog/p2p-sfu-and-mcu-webrtc-arc...
- fidotron 3y agoCost. SFUs don’t have to transcode the video, just pass buffers around and ensure both ends agree on the format. That is an enormously lighter process. Personally I think simulcast (sending multiple differently encoded streams) is almost always wrong for many Webrtc uses (especially mobile publishers) but in the OBS case it actually makes a lot more sense.
- EGreg 3y agoHow does WebRTC know what resolution to send? Or does it always send the original resolution?
- fidotron 3y agoThat all depends on how you set it up. Generally speaking a lot of WebRTC is about how the connection negotiates the parameters of the delivery of the different media, including codecs, resolution, etc. One track can be delivered over a connection in multiple different ways at once as well. If you want to know more you're probably best off going through the MDN docs about the WebRTC browser API and learning from that.