3 ms·

Traveling in Europe currently, but got curious. How many viewers can it support? RTMP usually goes to platforms that broadcast to many users. What about with W

by EGreg 3y ago

Traveling in Europe currently, but got curious. How many viewers can it support? RTMP usually goes to platforms that broadcast to many users. What about with WebRTC, can I have 100 viewers peer to peer? Maybe with TURN relays?

charcircuit 3y ago
That's an apples to oranges comparison. With proper infrastructure both can scale to many users. For streaming to many people peer to peer will be inefficient, so I would recommend not doing that.
- EGreg 3y ago
  How can OBS with the new WebRTC and WHIP+WHEP be used to stream to thousands of people at once, without using RTMP? And what is the proper infrastructure to scale WebRTC to thousands of listeners at once?
  - deleted 3y ago
    [deleted]
  - grogenaut 3y ago
    How can a webserver serve 10k people at once?
  - charcircuit 3y ago
    Cloudflare Stream has beta support for webrtc ingestion and playback. If you did more research you may find other services or projects for scaling webrtc streaming to handle many viewers and handling transcoding to lower quality for people without enough bandwidth. >And what is the proper infrastructure to scale WebRTC to thousands of listeners at once? It looks like a pool of ingestion servers and a CDN for viewers. Ingestion servers handle getting the stream from the streamer and encoding it into whatever formats are needed. The CDN handles distributing this stream to people who want to watch it.
  - Sean-Der 3y ago
    I have talked with companies that are already doing 100k+. I don't have the exact numbers but Millicast and Phenix both do very large audiences.
    - EGreg 3y ago
      How are they doing it is the question? What's the set up?
  - 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 ago
      If 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 ago
        Cost. 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 ago
        How does WebRTC know what resolution to send? Or does it always send the original resolution?
        fidotron 3y ago
        That 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.
jeroenhd 3y ago
Practically: however many your computer and uplink can serve. OBS needs to be tested, but this browser to browser test may give some indication: https://tensorworks.com.au/blog/webrtc-stream-limits-investigation/ https://tensorworks.com.au/blog/webrtc-stream-limits-investi.... If you've got 100 viewers and can manage to saturate a gigabit uplink (which can be difficult because of routing and other upstream crap) you should be able to send about 9mbps video + overhead, which is pretty close to Twitch's bandwidth cap. Because consumer ISPs generally don't have great routes between them and sustained gigabit uploads probably don't always work reliably because of overbooking with consumer lines, you'll probably be better off setting up an SFU on a cheap (temporary) cloud server somewhere. Theoretically: media streams are identified by a 32 bit number, so about 4 billion clients. Data streams are limited to 65535 endpoints (a signed 16 bit number with a reserved 0).
- martinald 3y ago
  Because consumer ISPs generally don't have great routes between them and sustained gigabit uploads probably don't always work reliably because of overbooking with consumer lines, you'll probably be better off setting up an SFU on a cheap (temporary) cloud server somewhere. Not sure why you think that? Maybe on cable modems, because DOCSIS is highly asymmetrical, but on FTTH GPON et al (pretty much the only technology which supports gigabit upload; docsis gigabit upload is extremely rare), there is no reason it couldn't saturate upstream at 1gigabit+. If anything, consumer ISPs are usually way more contended on the downlink side than the upstream side.
  - bluefirebrand 3y ago
    > Maybe on cable modems Maybe I'm wrong but I'm pretty sure cable modems are still wha the vast majority of consumer households have.
    - martinald 3y ago
      Yes but the parent is referring to gigabit upstream connections. Very few gigabit upstream services are over DOCSIS. I don't know of a single provider that offers gigabit upstream on docsis. In the UK Virgin Media offer 100mbit/sec up on their top tier (1gigabit down). I think the fastest Comcast goes in the US is 200mbit/sec up over docsis and that's only in certain areas.

by EGreg 3y ago

charcircuit 3y ago

That's an apples to oranges comparison. With proper infrastructure both can scale to many users. For streaming to many people peer to peer will be inefficient, so I would recommend not doing that.

EGreg 3y ago
How can OBS with the new WebRTC and WHIP+WHEP be used to stream to thousands of people at once, without using RTMP? And what is the proper infrastructure to scale WebRTC to thousands of listeners at once?
- deleted 3y ago
  [deleted]
- grogenaut 3y ago
  How can a webserver serve 10k people at once?
- charcircuit 3y ago
  Cloudflare Stream has beta support for webrtc ingestion and playback. If you did more research you may find other services or projects for scaling webrtc streaming to handle many viewers and handling transcoding to lower quality for people without enough bandwidth. >And what is the proper infrastructure to scale WebRTC to thousands of listeners at once? It looks like a pool of ingestion servers and a CDN for viewers. Ingestion servers handle getting the stream from the streamer and encoding it into whatever formats are needed. The CDN handles distributing this stream to people who want to watch it.
- Sean-Der 3y ago
  I have talked with companies that are already doing 100k+. I don't have the exact numbers but Millicast and Phenix both do very large audiences.
  - EGreg 3y ago
    How are they doing it is the question? What's the set up?
- 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 ago
    If 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 ago
      Cost. 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 ago
        How does WebRTC know what resolution to send? Or does it always send the original resolution?
        fidotron 3y ago
        That 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.

jeroenhd 3y ago

Practically: however many your computer and uplink can serve. OBS needs to be tested, but this browser to browser test may give some indication: https://tensorworks.com.au/blog/webrtc-stream-limits-investigation/ https://tensorworks.com.au/blog/webrtc-stream-limits-investi.... If you've got 100 viewers and can manage to saturate a gigabit uplink (which can be difficult because of routing and other upstream crap) you should be able to send about 9mbps video + overhead, which is pretty close to Twitch's bandwidth cap. Because consumer ISPs generally don't have great routes between them and sustained gigabit uploads probably don't always work reliably because of overbooking with consumer lines, you'll probably be better off setting up an SFU on a cheap (temporary) cloud server somewhere. Theoretically: media streams are identified by a 32 bit number, so about 4 billion clients. Data streams are limited to 65535 endpoints (a signed 16 bit number with a reserved 0).

martinald 3y ago
Because consumer ISPs generally don't have great routes between them and sustained gigabit uploads probably don't always work reliably because of overbooking with consumer lines, you'll probably be better off setting up an SFU on a cheap (temporary) cloud server somewhere. Not sure why you think that? Maybe on cable modems, because DOCSIS is highly asymmetrical, but on FTTH GPON et al (pretty much the only technology which supports gigabit upload; docsis gigabit upload is extremely rare), there is no reason it couldn't saturate upstream at 1gigabit+. If anything, consumer ISPs are usually way more contended on the downlink side than the upstream side.
- bluefirebrand 3y ago
  > Maybe on cable modems Maybe I'm wrong but I'm pretty sure cable modems are still wha the vast majority of consumer households have.
  - martinald 3y ago
    Yes but the parent is referring to gigabit upstream connections. Very few gigabit upstream services are over DOCSIS. I don't know of a single provider that offers gigabit upstream on docsis. In the UK Virgin Media offer 100mbit/sec up on their top tier (1gigabit down). I think the fastest Comcast goes in the US is 200mbit/sec up over docsis and that's only in certain areas.