9 ms·

OBS merges WebRTC support

450 points by Sean-Der 3y ago

Sean-Der 3y ago
WebRTC support has been merged into OBS. This is going to bring some really exciting new things to the space! * Serverless Streaming - WebRTC is P2P so you can video right into your browser. You don’t have to stand up a server anymore to stream for a small audience. * Sub-Second Latency - Create content and interact with viewers instantly. There is something magical about having a real conversation with your viewers. * Multitrack Input - Upload your transcodes instead of generating then server side. Give viewers multiple video tracks to see action from all sides. * Mobility - WebRTC lets you switch networks at any time. Go from WiFi -> Mobile with zero interruptions. Try it out today with Broadcast Box. A reference server implementation. https://github.com/glimesh/broadcast-box https://github.com/glimesh/broadcast-box. The PR to add WebRTC to OBS https://github.com/obsproject/obs-studio/pull/7926 https://github.com/obsproject/obs-studio/pull/7926 ----- So many people went into making this happen. This was a colossal undertaking that different people have working on for over 6 months. Sergio Murillo - Created WHIP. The only reason this could be added to OBS. Luke Strickland - Created Broadcast Box. The reference server we developed against Paul-Louis Ageneau - Creator of libdatachannel. The library used to add WebRTC support to OBS. Colin Edwards - Started the project to add WebRTC into OBS John Bradley, tt2468, pkv - Developers who worked on the code itself RytoEx, tytan652 - Lots of feedback and reviews ----- Have fun using it! If you have any questions/feedback/improvement ideas I would love to hear.
- 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?
  - 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.
- felipellrocha 3y ago
  > Sub-Second Latency - Create content and interact with viewers instantly. There is something magical about having a real conversation with your viewers. How is this possible?
  - gruez 3y ago
    Why shouldn't it be possible? Screen share on a Zoom/Teams meeting is basically a stream with sub-second latency.
  - hsudhduhsh 3y ago
    most connections today are subsecond... a second is a lot of time. also this is probably only taking California as the whole world, like everyone does.
    - imtringued 3y ago
      I have less latency to California than most Bluetooth headsets have to your ears.
  - Karrot_Kream 3y ago
    WebRTC attempts to set up a direct connection between the streamer and the receiver so packets are being sent over directly. This doesn't always work out, say if there's bad connectivity (e.g. NAT) somewhere so the connection uses a TURN server or if there's a conference call situation where an SFU is involved, but usually it works.
    - andybak 3y ago
      SFU?
      - Karrot_Kream 3y ago
        SFUs, or Selective Forwarding Units, receive media streams from multiple participants but only forward a subset of those streams to certain participants. For example, if you're in a Webinar of 20 people, instead of opening up direct connections to all 19 other participants (and having every other participant do so as well), you can open up a direct connection to the presenter and an SFU which will send you an aggregated, downsampled stream of all the other participants. It reduces direct connections across large calls and saves on processing power across all participants by aggregation.
- sitkack 3y ago
  Can this do web RTC between servers? Can we construct a tree of OBS instances? The numbers are purely illustrative. I don’t know what OPS can actually do but let’s say each OBS server can handle 50 connections that means if we had a two level deep tree, we could handle 2500 participants in a single call.
  - pavlov 3y ago
    This is output only (more specifically over WHIP, WebRTC-HTTP Ingest Protocol). For incoming connections and compositing them you need something beyond OBS. Gstreamer is one option.
  - Sean-Der 3y ago
    I don't have an idea on how to do cascading OBS instances. I should write some software to make this easy though. I want to make 'self hosting' as easy as possible. I think https://github.com/glimesh/broadcast-box https://github.com/glimesh/broadcast-box will fill that gap for now. For my own usage I run WebRTC servers and have them 'replicate' the video traffic. LiveKit did a write up on this with some good graphics https://blog.livekit.io/scaling-webrtc-with-distributed-mesh/ https://blog.livekit.io/scaling-webrtc-with-distributed-mesh...
    - prox 3y ago
      What I would like to see is a Twitch like experience but within your own space, aka what a website is for the web, and the hoster is nothing more than a facilitator. So you pay for the basic tech and maybe bandwidth but the rest is up to the streamer. Would be great to have a real alternative to Twitch that’s completely your own. People could still federate, but there is also a mainhub (broadcastbox.com or whatever) Anyway it’s super exciting stuff! Great work!
      - bluefirebrand 3y ago
        I have been thinking about this a bit, kind of like a "what if you could set up a streaming website as easily as a wordpress blog"
- viraptor 3y ago
  > Serverless Streaming - WebRTC is P2P As I understand webrtc, it describes the connection wrapping and the streams / negotiation, but not the discovery part. Which means it's about as p2p as http - if you add a way to find the endpoint and open sockets, you can make peers talk. Is there something more in the OBS implementation that makes it more p2p? Am I missing something?
  - notatoad 3y ago
    i think the point is that the streams themselves require a lot of bandwidth, so you can make the expensive part of the process peer-to-peer instead of having to route the whole thing through a server and pay both inbound and outbound bandwidth costs on the stream. it's not really meant to be a useful tool for making a pure peer-to-peer video service.
    - viraptor 3y ago
      Ok, so it's more of a "direct connection" than "peer to peer" scenario. That makes sense.
      - jraph 3y ago
        Doesn't P2P always require some kind of discovery mechanism unless peers know each others? For example for P2P file sharing with Torrent files, a central server (a tracker) that list the current peers? What is different between this and WebRTC? It's only partially decentralized but we still call this P2P, in both cases.
        Sean-Der 3y ago
        Yes WebRTC does require a discovery mechanism. That is where WHIP/Signaling comes into play. I have a chapter on signaling here https://webrtcforthecurious.com/docs/02-signaling/ https://webrtcforthecurious.com/docs/02-signaling/ I have an example of WebRTC without signaling https://github.com/pion/offline-browser-communication https://github.com/pion/offline-browser-communication. Each side has to agree on things ahead of time. Useful for security cameras/IoT/LAN stuff though!
- ehsankia 3y ago
  Woah, so if I understand this correctly, I can just put whatever streamkey i want in OBS with https://b.siobud.com/api/whip https://b.siobud.com/api/whip as my server, then my friend puts the same key on BroadcastBox hosted website and that's it? That's amazing. I do a lot of 1:1 streaming, sometimes with discord, sometimes with Twitch, but this is much better.
  - Sean-Der 3y ago
    Yea exactly! https://b.siobud.com https://b.siobud.com might not be always available. So best to host yourself for anything important :) Excited for you to use it. Send any ideas my way for improvement.
- eminence32 3y ago
  Thanks for all your work getting this PR merged! I've been trying it out for a while now (streaming to a self-hosted broadcast-box), and almost everyone who views the stream says that the video will freeze for 1 to 2 seconds every now and again (every few minutes). Audio is uninterrupted. Any hints about how I can debug this?
  - doctorpangloss 3y ago
    In my opinion, moderate your expectations of non-libwebrtc implementations like the one used in this feature. Here's some speculation: Most users will experience non-libwebrtc WebRTC bugs (like OBS users). 1% of users who experience bugs in OBS WebRTC will report enough telemetry to fix the bug. But 99% of all of OBS's userbase uses Chrome, Edge or Safari, and maybe 50% of those (more than enough) report telemetry. So if their WebRTC bug was hardware / network specific - the bugs that matter - libwebrtc will have observed it and by now, probably fixed it. Despite telemetry from hundreds of millions of users every day, it still took years for libwebrtc to reach truly robust, flawless stability on all the platforms it deploys on. It's a complex technology.
  - Sean-Der 3y ago
    Sorry about that! chrome://webrtc-internals should tell you the exact reason. My guess is packet loss and then it recovers on the keyframe. In the next day or two I am gonna open a PR to set NACK buffer properly. Right now it is too small :/ Sorry you are hitting issues. Will try my best to fix it up! Email me sean@pion.ly and would love to make sure we get it working 100%. I bet other users are hitting the same issues and not sharing.
    - eminence32 3y ago
      Thanks for your hint about chrome://webrtc-internals -- I'll see what that tells me!
  - wisdow 3y ago
    Been experiencing the same issue. I tried to figure what causes this but without success. If you have any idea i'm down to discuss about it.
- throwaway485 3y ago
  > * Multitrack Input - Upload your transcodes instead of generating then server side. Give viewers multiple video tracks to see action from all sides. I've always wanted this. Instead of the streamer switching video inputs we could select from the viewer-side which perspective we want. I've also thought about things like NASCAR partnering with Valve/Steam to use their Valve Index for 360-degree views from each car on the track. I don't know why they're not marking VR to people who love NASCAR, it'd be such an odd and likely successful niche. It'd be cool to accept-in multiple video inputs and even patch them together in realtime on the viewer side (unless they're specifically disparate).
- gloosx 3y ago
  As a dev who works with WebRTC a lot, debunking some of these claims * Serverless Streaming - WebRTC is P2P so you can video right into your browser. You don’t have to stand up a server anymore to stream for a small audience. > Only possible in an ideal world, where NAT doesn't exist, in reality, you need to traverse NAT and it is NOT a serverless process. * Sub-Second Latency - Create content and interact with viewers instantly. There is something magical about having a real conversation with your viewers. > Only possible in an ideal world, where machines are very close to each other. In reality, you need expensive world-wide TURN clusters on top-notch infrastructure to ensure <100ms latencies you want. * Mobility - WebRTC lets you switch networks at any time. Go from WiFi -> Mobile with zero interruptions. > In fact, an interruption is happening when network conditions change – since you need to negotiate connectivity again. It is not seamless.
  - fulafel 3y ago
    The app data only need to go via a server if you don't have IPv6 and your IPv4 NAT is in the minority of NAT boxes that breaks the usual P2P NAT workarounds[1] like UDP hole punching. (Firewalls can of course also be configured to block it but that's another kettle of fish) [1] https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/217599-understand-nat-to-enable-peer-to-peer-co.html https://www.cisco.com/c/en/us/support/docs/ip/network-addres...
    - drdaeman 3y ago
      I haven't bothered to learn why, but if both broadcaster and viewer are behind a symmetric NAT, usual STUN tricks don't always seem to work in practice. At least they haven't worked for me. I have a DIY WebRTC forwarder for a RTSP stream, that lives on a home server behind a NAT. It has NAT because it lives in a cgroup that's isolated to IoT VLAN, and I haven't originally planned on WebRTC there, hoping I could make it work with restreaming over HTTP or Websockets. The NAT there is of the most common type: nftables' masquerade statement for the appropriate output interface, the usual conntrack allow established,related rule, and rule that allows outbound connections. For whatever reason, WebRTC only worked for me when my viewing device wasn't behind any other NATs. Now, this is not a proper argument. Being a very lazy ass I haven't bothered with diagnostics so I don't know why it hadn't worked. I was already quite frustrated with various cross-browser JS shenanigans and after checking that STUN was indeed configured but had not worked, I've just punched a couple of port forwards and called it a day. For whatever reason P2P streaming seem to work somewhat worse in practice than it should've been in theory. Usual computer leprechauns, I guess.
- erlend_sh 3y ago
  > You don’t have to stand up a server anymore to stream for a small audience. Now this is actually HUGE. It means Twitch has far less power as a gateway for greenfield streamers.
  - starttoaster 3y ago
    Disagree. There is far more to Twitch than just "video goes here." There's the chat system for one, which this doesn't solve for. An important part of streaming is the social aspect of it to many, in the chatroom. It's also a way for your fans to communicate back to you. Sure they can open up your stream in a browser and chat with you in a Discord, but you're talking about requiring 2 tools being open as opposed to one. And that's not even the worst part: the subscription/follower system. The goal for any greenfield streamer is to gain a follower base. These followers and concurrent viewers are what allows you to get a "subscription" button for people to pay you. Otherwise you're asking for donations via Patreon or something similar? However, if you're getting your subscription money via Patreon, you're missing out on potential boat loads of money from Twitch Prime subscribers, where every Twitch user that also has an Amazon Prime subscription can send you one free subscription per month; a LOT of Twitch streamers make a lot of additional money this way, at no additional cost to the viewer. Things you're giving up as a greenfield streamer by rolling their own streaming platform: * The beginning of a follower base on your destination platform (Twitch) * A "single pane of glass" for viewing your stream, chatting with you and other viewers, and giving you subscription/donation money. This is a deal breaker for a non-negligible number of people, and your follower base might not grow as large or as quickly as you'd like. * Twitch Prime subscription money.
prahladyeri 3y ago
If only OBS was somewhat lighter, I'd have used it. You need an Intel i5 or Ryzen 1300x processor for a "minimum requirements", imagine what would it take for a decent performance! Instead, I use another app called ShareX [1] which is much lighter on the OS and processor. It may not have all the features but you can easily create a screencast or recording session with ease. [1]: https://github.com/ShareX/ShareX https://github.com/ShareX/ShareX
- mikece 3y ago
  As fast as processors are these days I don't see this as a valid complaint (especially with how inexpensive machines powered by the Apple M1 are these days).
- lucideer 3y ago
  I haven't used ShareX so I may be missing something here, but the website seems to indicate it's a screen capture utility. Does it do more? OBS is not a screen capture utility.
  - CharlesW 3y ago
    > OBS is not a screen capture utility. I've been looking for a way to record my screen and webcam as separate files and so far OBS¹ seems like it might be the only tool that can do that. Is that not a good use for OBS? ¹ https://obsproject.com/forum/resources/source-record.1285/ https://obsproject.com/forum/resources/source-record.1285/)
    - circuit10 3y ago
      I guess they mean not just a screen capture utility
    - lucideer 3y ago
      Sorry I should've been clearer: it can certainly be used to capture your screen. It's just an extremely ancillary subfeature.
  - 3y ago
mikece 3y ago
Will this support OBS being the conferencing/recording point such that one can have multiple video remotes in a live-streamed video (like StreamYard but open source and not browser-based)?
- pavlov 3y ago
  Not by itself. This adds the option of streaming output using WHIP, the WebRTC-HTTP Ingest Protocol [1]. [1] https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html
- Sean-Der 3y ago
  I hope so soon! I now prefer using OBS vs Chrome screenshare because the quality is so much better. Conferencing providers just need to add WHIP support. It is trivial to add.
  - mikece 3y ago
    > Conferencing providers just need to add WHIP support. It is trivial to add. That would be awesome for consumers... but horrible for the business model of conferencing providers which is why it won't happen.
  - aftbit 3y ago
    Has anyone started an issue or PR for Jitsi? We use them exclusively for work. I'd love to be able to use OBS with work streams without awkward virtual webcam hacks.
winrid 3y ago
Nice, but curious, why use char* so much in a c++ project?
- mackal 3y ago
  Most of the c string usage appears to be just for libobs, which is a C library. They have a few constants that are perfectly fine and the rest of their string usage is actually std::string ...
nubinetwork 3y ago
I wonder if this works for input, or if it's output only. I experimented with using webrtc for speedrunning races, but ran into issues because I didn't know how to interactively crop the inputs in order to stitch them back together and stream the output to twitch.
- grogenaut 3y ago
  I'm betting it's output only. But obs cash take many many sources including a browser window that is in memory. You can put a player in one of those hooked to the stream, like you can render twitch chat
- Sean-Der 3y ago
  It is output only (for now). I will be adding input also. Making it easier for people to build streams like Twitch's Guest Star[0]. Just implementing the WHIP/WHEP, then we are going to see if we can add some batteries/better experience that is OBS specific. [0] https://help.twitch.tv/s/article/guest-star?language=en_US https://help.twitch.tv/s/article/guest-star?language=en_US
seydor 3y ago
webrtc is such a complex technology still after so many years. I wonder why web standards didnt decide to just deprecate old tech and create something that is usable out of the box without stun/turn servers and all the other complexity that i don't even know. In the year 2001 it was much simpler to set up an all-to-many video chat with Flash and an open source media server. it feels like this tech has been chasing its tail
- torginus 3y ago
  The issue comes from the technology using UDP which creates all sorts of funky networking situations when NAT is involved necessitating turn/stun. I think that will be unavoidable unless HTTP3/QUIC or IPv6 gains widespread support on all kinds of network infrastructure.
  - sylware 3y ago
    That's why they should have eaten the bullet: ipv6 and tcp, only.
    - predictabl3 3y ago
      Except they wanted to build something usable? If I could snap my fingers and make IPv6 deployment and usability, I and I'm sure WebRTC folks would. This entire stance is even more hard to mesh with the real world given how long WebRTC has been in development and use.
      - sylware 3y ago
        Well, the idea behind would be to move to a clean ipv6/tcp protocol stack at the same pace than ipv6 deployment. The best compromise would have been a dual stack: the clean pure p2p ipv6/tcp, and the brain f*cked ipv4/nat/upnp/turn/stun/etc. To have a clean and brutal split between the 2. In my country, people would mostly run the clean ipv6/tcp protocol stack. And I am thinking REALLY simple: no transcode in the protocol (only the node will decide if it needs to transcode), one stream, buffered (it's not a video call). Yeah... excrutiatingly simple, then with many alternative implementations, aka sane. But, it is kind of a dream, I know CDNs and streaming services won't let that happen in any way, I would not be surprised to see some DDOS-ing "from" them to keep people slaves of their big tech "centralized" services.
Eruntalon 3y ago
[flagged]
password4321 3y ago
Related (somewhat): WebRTC support being added to FFmpeg https://news.ycombinator.com/item?id=36130191 https://news.ycombinator.com/item?id=36130191 10 days ago
- sylware 3y ago
  Good news for my custom, plain and simple, C coded media player based on ffmpeg. I'll be able to view such streams, but... ... how I can be a contributor of such p2p stream without a big tech web engine? (I use only noscript/basic (x)html browsers). I could setup a "node" (should be plain and simple C coded) on my desktop computer, then from this node, I would extract the stream itself and watch it locally (I have a 800MBits uplink, and I know what IP diffserv with its ethernet translation is). If the specs/protocol stack are reasonable and not too much convoluted, I would even be able to code such node (based on ffmpeg, very probably). AND... if this p2p network is actually good and works IRL, do you really think the CDNs and streaming platforms will let it exist without a little bit of DDOS-ing...?
at_a_remove 3y ago
I wonder if there's a handy client and, if so, how sophisticated it might be.
sylware 3y ago
Cannot wait to see the "doc" independent of all streaming platforms... :)
rektide 3y ago
Yet another submission where WHIP & the WebRTC are conflated. This is due using http to stream video to another service which can actually do WebRTC. Still excellent still a huge win, but also a pretty big distion. Users still need considerably more to actually get online. Same conflation happened for ffmpeg getting WHIP. https://news.ycombinator.com/item?id=36130191 https://news.ycombinator.com/item?id=36130191
- Sean-Der 3y ago
  Sorry I might be confused, but `This is due using http to stream video to another service which can actually do WebRTC` I don’t think is right. WHIP is WebRTC signaling only. It just standardizes using a HTTP POST to exchange Offer/Answer. No media flows over HTTP.
sharts 3y ago
Nice

450 points by Sean-Der 3y ago

WebRTC support has been merged into OBS. This is going to bring some really exciting new things to the space! * Serverless Streaming - WebRTC is P2P so you can video right into your browser. You don’t have to stand up a server anymore to stream for a small audience. * Sub-Second Latency - Create content and interact with viewers instantly. There is something magical about having a real conversation with your viewers. * Multitrack Input - Upload your transcodes instead of generating then server side. Give viewers multiple video tracks to see action from all sides. * Mobility - WebRTC lets you switch networks at any time. Go from WiFi -> Mobile with zero interruptions. Try it out today with Broadcast Box. A reference server implementation. https://github.com/glimesh/broadcast-box https://github.com/glimesh/broadcast-box. The PR to add WebRTC to OBS https://github.com/obsproject/obs-studio/pull/7926 https://github.com/obsproject/obs-studio/pull/7926 ----- So many people went into making this happen. This was a colossal undertaking that different people have working on for over 6 months. Sergio Murillo - Created WHIP. The only reason this could be added to OBS. Luke Strickland - Created Broadcast Box. The reference server we developed against Paul-Louis Ageneau - Creator of libdatachannel. The library used to add WebRTC support to OBS. Colin Edwards - Started the project to add WebRTC into OBS John Bradley, tt2468, pkv - Developers who worked on the code itself RytoEx, tytan652 - Lots of feedback and reviews ----- Have fun using it! If you have any questions/feedback/improvement ideas I would love to hear.

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?
- 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.
felipellrocha 3y ago
> Sub-Second Latency - Create content and interact with viewers instantly. There is something magical about having a real conversation with your viewers. How is this possible?
- gruez 3y ago
  Why shouldn't it be possible? Screen share on a Zoom/Teams meeting is basically a stream with sub-second latency.
- hsudhduhsh 3y ago
  most connections today are subsecond... a second is a lot of time. also this is probably only taking California as the whole world, like everyone does.
  - imtringued 3y ago
    I have less latency to California than most Bluetooth headsets have to your ears.
- Karrot_Kream 3y ago
  WebRTC attempts to set up a direct connection between the streamer and the receiver so packets are being sent over directly. This doesn't always work out, say if there's bad connectivity (e.g. NAT) somewhere so the connection uses a TURN server or if there's a conference call situation where an SFU is involved, but usually it works.
  - andybak 3y ago
    SFU?
    - Karrot_Kream 3y ago
      SFUs, or Selective Forwarding Units, receive media streams from multiple participants but only forward a subset of those streams to certain participants. For example, if you're in a Webinar of 20 people, instead of opening up direct connections to all 19 other participants (and having every other participant do so as well), you can open up a direct connection to the presenter and an SFU which will send you an aggregated, downsampled stream of all the other participants. It reduces direct connections across large calls and saves on processing power across all participants by aggregation.
sitkack 3y ago
Can this do web RTC between servers? Can we construct a tree of OBS instances? The numbers are purely illustrative. I don’t know what OPS can actually do but let’s say each OBS server can handle 50 connections that means if we had a two level deep tree, we could handle 2500 participants in a single call.
- pavlov 3y ago
  This is output only (more specifically over WHIP, WebRTC-HTTP Ingest Protocol). For incoming connections and compositing them you need something beyond OBS. Gstreamer is one option.
- Sean-Der 3y ago
  I don't have an idea on how to do cascading OBS instances. I should write some software to make this easy though. I want to make 'self hosting' as easy as possible. I think https://github.com/glimesh/broadcast-box https://github.com/glimesh/broadcast-box will fill that gap for now. For my own usage I run WebRTC servers and have them 'replicate' the video traffic. LiveKit did a write up on this with some good graphics https://blog.livekit.io/scaling-webrtc-with-distributed-mesh/ https://blog.livekit.io/scaling-webrtc-with-distributed-mesh...
  - prox 3y ago
    What I would like to see is a Twitch like experience but within your own space, aka what a website is for the web, and the hoster is nothing more than a facilitator. So you pay for the basic tech and maybe bandwidth but the rest is up to the streamer. Would be great to have a real alternative to Twitch that’s completely your own. People could still federate, but there is also a mainhub (broadcastbox.com or whatever) Anyway it’s super exciting stuff! Great work!
    - bluefirebrand 3y ago
      I have been thinking about this a bit, kind of like a "what if you could set up a streaming website as easily as a wordpress blog"
viraptor 3y ago
> Serverless Streaming - WebRTC is P2P As I understand webrtc, it describes the connection wrapping and the streams / negotiation, but not the discovery part. Which means it's about as p2p as http - if you add a way to find the endpoint and open sockets, you can make peers talk. Is there something more in the OBS implementation that makes it more p2p? Am I missing something?
- notatoad 3y ago
  i think the point is that the streams themselves require a lot of bandwidth, so you can make the expensive part of the process peer-to-peer instead of having to route the whole thing through a server and pay both inbound and outbound bandwidth costs on the stream. it's not really meant to be a useful tool for making a pure peer-to-peer video service.
  - viraptor 3y ago
    Ok, so it's more of a "direct connection" than "peer to peer" scenario. That makes sense.
    - jraph 3y ago
      Doesn't P2P always require some kind of discovery mechanism unless peers know each others? For example for P2P file sharing with Torrent files, a central server (a tracker) that list the current peers? What is different between this and WebRTC? It's only partially decentralized but we still call this P2P, in both cases.
      - Sean-Der 3y ago
        Yes WebRTC does require a discovery mechanism. That is where WHIP/Signaling comes into play. I have a chapter on signaling here https://webrtcforthecurious.com/docs/02-signaling/ https://webrtcforthecurious.com/docs/02-signaling/ I have an example of WebRTC without signaling https://github.com/pion/offline-browser-communication https://github.com/pion/offline-browser-communication. Each side has to agree on things ahead of time. Useful for security cameras/IoT/LAN stuff though!
ehsankia 3y ago
Woah, so if I understand this correctly, I can just put whatever streamkey i want in OBS with https://b.siobud.com/api/whip https://b.siobud.com/api/whip as my server, then my friend puts the same key on BroadcastBox hosted website and that's it? That's amazing. I do a lot of 1:1 streaming, sometimes with discord, sometimes with Twitch, but this is much better.
- Sean-Der 3y ago
  Yea exactly! https://b.siobud.com https://b.siobud.com might not be always available. So best to host yourself for anything important :) Excited for you to use it. Send any ideas my way for improvement.
eminence32 3y ago
Thanks for all your work getting this PR merged! I've been trying it out for a while now (streaming to a self-hosted broadcast-box), and almost everyone who views the stream says that the video will freeze for 1 to 2 seconds every now and again (every few minutes). Audio is uninterrupted. Any hints about how I can debug this?
- doctorpangloss 3y ago
  In my opinion, moderate your expectations of non-libwebrtc implementations like the one used in this feature. Here's some speculation: Most users will experience non-libwebrtc WebRTC bugs (like OBS users). 1% of users who experience bugs in OBS WebRTC will report enough telemetry to fix the bug. But 99% of all of OBS's userbase uses Chrome, Edge or Safari, and maybe 50% of those (more than enough) report telemetry. So if their WebRTC bug was hardware / network specific - the bugs that matter - libwebrtc will have observed it and by now, probably fixed it. Despite telemetry from hundreds of millions of users every day, it still took years for libwebrtc to reach truly robust, flawless stability on all the platforms it deploys on. It's a complex technology.
- Sean-Der 3y ago
  Sorry about that! chrome://webrtc-internals should tell you the exact reason. My guess is packet loss and then it recovers on the keyframe. In the next day or two I am gonna open a PR to set NACK buffer properly. Right now it is too small :/ Sorry you are hitting issues. Will try my best to fix it up! Email me sean@pion.ly and would love to make sure we get it working 100%. I bet other users are hitting the same issues and not sharing.
  - eminence32 3y ago
    Thanks for your hint about chrome://webrtc-internals -- I'll see what that tells me!
- wisdow 3y ago
  Been experiencing the same issue. I tried to figure what causes this but without success. If you have any idea i'm down to discuss about it.
throwaway485 3y ago
> * Multitrack Input - Upload your transcodes instead of generating then server side. Give viewers multiple video tracks to see action from all sides. I've always wanted this. Instead of the streamer switching video inputs we could select from the viewer-side which perspective we want. I've also thought about things like NASCAR partnering with Valve/Steam to use their Valve Index for 360-degree views from each car on the track. I don't know why they're not marking VR to people who love NASCAR, it'd be such an odd and likely successful niche. It'd be cool to accept-in multiple video inputs and even patch them together in realtime on the viewer side (unless they're specifically disparate).
gloosx 3y ago
As a dev who works with WebRTC a lot, debunking some of these claims * Serverless Streaming - WebRTC is P2P so you can video right into your browser. You don’t have to stand up a server anymore to stream for a small audience. > Only possible in an ideal world, where NAT doesn't exist, in reality, you need to traverse NAT and it is NOT a serverless process. * Sub-Second Latency - Create content and interact with viewers instantly. There is something magical about having a real conversation with your viewers. > Only possible in an ideal world, where machines are very close to each other. In reality, you need expensive world-wide TURN clusters on top-notch infrastructure to ensure <100ms latencies you want. * Mobility - WebRTC lets you switch networks at any time. Go from WiFi -> Mobile with zero interruptions. > In fact, an interruption is happening when network conditions change – since you need to negotiate connectivity again. It is not seamless.
- fulafel 3y ago
  The app data only need to go via a server if you don't have IPv6 and your IPv4 NAT is in the minority of NAT boxes that breaks the usual P2P NAT workarounds[1] like UDP hole punching. (Firewalls can of course also be configured to block it but that's another kettle of fish) [1] https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/217599-understand-nat-to-enable-peer-to-peer-co.html https://www.cisco.com/c/en/us/support/docs/ip/network-addres...
  - drdaeman 3y ago
    I haven't bothered to learn why, but if both broadcaster and viewer are behind a symmetric NAT, usual STUN tricks don't always seem to work in practice. At least they haven't worked for me. I have a DIY WebRTC forwarder for a RTSP stream, that lives on a home server behind a NAT. It has NAT because it lives in a cgroup that's isolated to IoT VLAN, and I haven't originally planned on WebRTC there, hoping I could make it work with restreaming over HTTP or Websockets. The NAT there is of the most common type: nftables' masquerade statement for the appropriate output interface, the usual conntrack allow established,related rule, and rule that allows outbound connections. For whatever reason, WebRTC only worked for me when my viewing device wasn't behind any other NATs. Now, this is not a proper argument. Being a very lazy ass I haven't bothered with diagnostics so I don't know why it hadn't worked. I was already quite frustrated with various cross-browser JS shenanigans and after checking that STUN was indeed configured but had not worked, I've just punched a couple of port forwards and called it a day. For whatever reason P2P streaming seem to work somewhat worse in practice than it should've been in theory. Usual computer leprechauns, I guess.
erlend_sh 3y ago
> You don’t have to stand up a server anymore to stream for a small audience. Now this is actually HUGE. It means Twitch has far less power as a gateway for greenfield streamers.
- starttoaster 3y ago
  Disagree. There is far more to Twitch than just "video goes here." There's the chat system for one, which this doesn't solve for. An important part of streaming is the social aspect of it to many, in the chatroom. It's also a way for your fans to communicate back to you. Sure they can open up your stream in a browser and chat with you in a Discord, but you're talking about requiring 2 tools being open as opposed to one. And that's not even the worst part: the subscription/follower system. The goal for any greenfield streamer is to gain a follower base. These followers and concurrent viewers are what allows you to get a "subscription" button for people to pay you. Otherwise you're asking for donations via Patreon or something similar? However, if you're getting your subscription money via Patreon, you're missing out on potential boat loads of money from Twitch Prime subscribers, where every Twitch user that also has an Amazon Prime subscription can send you one free subscription per month; a LOT of Twitch streamers make a lot of additional money this way, at no additional cost to the viewer. Things you're giving up as a greenfield streamer by rolling their own streaming platform: * The beginning of a follower base on your destination platform (Twitch) * A "single pane of glass" for viewing your stream, chatting with you and other viewers, and giving you subscription/donation money. This is a deal breaker for a non-negligible number of people, and your follower base might not grow as large or as quickly as you'd like. * Twitch Prime subscription money.

prahladyeri 3y ago

If only OBS was somewhat lighter, I'd have used it. You need an Intel i5 or Ryzen 1300x processor for a "minimum requirements", imagine what would it take for a decent performance! Instead, I use another app called ShareX [1] which is much lighter on the OS and processor. It may not have all the features but you can easily create a screencast or recording session with ease. [1]: https://github.com/ShareX/ShareX https://github.com/ShareX/ShareX

mikece 3y ago
As fast as processors are these days I don't see this as a valid complaint (especially with how inexpensive machines powered by the Apple M1 are these days).
lucideer 3y ago
I haven't used ShareX so I may be missing something here, but the website seems to indicate it's a screen capture utility. Does it do more? OBS is not a screen capture utility.
- CharlesW 3y ago
  > OBS is not a screen capture utility. I've been looking for a way to record my screen and webcam as separate files and so far OBS¹ seems like it might be the only tool that can do that. Is that not a good use for OBS? ¹ https://obsproject.com/forum/resources/source-record.1285/ https://obsproject.com/forum/resources/source-record.1285/)
  - circuit10 3y ago
    I guess they mean not just a screen capture utility
  - lucideer 3y ago
    Sorry I should've been clearer: it can certainly be used to capture your screen. It's just an extremely ancillary subfeature.
- 3y ago

mikece 3y ago

Will this support OBS being the conferencing/recording point such that one can have multiple video remotes in a live-streamed video (like StreamYard but open source and not browser-based)?

pavlov 3y ago
Not by itself. This adds the option of streaming output using WHIP, the WebRTC-HTTP Ingest Protocol [1]. [1] https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html
Sean-Der 3y ago
I hope so soon! I now prefer using OBS vs Chrome screenshare because the quality is so much better. Conferencing providers just need to add WHIP support. It is trivial to add.
- mikece 3y ago
  > Conferencing providers just need to add WHIP support. It is trivial to add. That would be awesome for consumers... but horrible for the business model of conferencing providers which is why it won't happen.
- aftbit 3y ago
  Has anyone started an issue or PR for Jitsi? We use them exclusively for work. I'd love to be able to use OBS with work streams without awkward virtual webcam hacks.

winrid 3y ago

Nice, but curious, why use char* so much in a c++ project?

mackal 3y ago
Most of the c string usage appears to be just for libobs, which is a C library. They have a few constants that are perfectly fine and the rest of their string usage is actually std::string ...

nubinetwork 3y ago

I wonder if this works for input, or if it's output only. I experimented with using webrtc for speedrunning races, but ran into issues because I didn't know how to interactively crop the inputs in order to stitch them back together and stream the output to twitch.

grogenaut 3y ago
I'm betting it's output only. But obs cash take many many sources including a browser window that is in memory. You can put a player in one of those hooked to the stream, like you can render twitch chat
Sean-Der 3y ago
It is output only (for now). I will be adding input also. Making it easier for people to build streams like Twitch's Guest Star[0]. Just implementing the WHIP/WHEP, then we are going to see if we can add some batteries/better experience that is OBS specific. [0] https://help.twitch.tv/s/article/guest-star?language=en_US https://help.twitch.tv/s/article/guest-star?language=en_US

seydor 3y ago

webrtc is such a complex technology still after so many years. I wonder why web standards didnt decide to just deprecate old tech and create something that is usable out of the box without stun/turn servers and all the other complexity that i don't even know. In the year 2001 it was much simpler to set up an all-to-many video chat with Flash and an open source media server. it feels like this tech has been chasing its tail

torginus 3y ago
The issue comes from the technology using UDP which creates all sorts of funky networking situations when NAT is involved necessitating turn/stun. I think that will be unavoidable unless HTTP3/QUIC or IPv6 gains widespread support on all kinds of network infrastructure.
- sylware 3y ago
  That's why they should have eaten the bullet: ipv6 and tcp, only.
  - predictabl3 3y ago
    Except they wanted to build something usable? If I could snap my fingers and make IPv6 deployment and usability, I and I'm sure WebRTC folks would. This entire stance is even more hard to mesh with the real world given how long WebRTC has been in development and use.
    - sylware 3y ago
      Well, the idea behind would be to move to a clean ipv6/tcp protocol stack at the same pace than ipv6 deployment. The best compromise would have been a dual stack: the clean pure p2p ipv6/tcp, and the brain f*cked ipv4/nat/upnp/turn/stun/etc. To have a clean and brutal split between the 2. In my country, people would mostly run the clean ipv6/tcp protocol stack. And I am thinking REALLY simple: no transcode in the protocol (only the node will decide if it needs to transcode), one stream, buffered (it's not a video call). Yeah... excrutiatingly simple, then with many alternative implementations, aka sane. But, it is kind of a dream, I know CDNs and streaming services won't let that happen in any way, I would not be surprised to see some DDOS-ing "from" them to keep people slaves of their big tech "centralized" services.

Eruntalon 3y ago

[flagged]

password4321 3y ago

Related (somewhat): WebRTC support being added to FFmpeg https://news.ycombinator.com/item?id=36130191 https://news.ycombinator.com/item?id=36130191 10 days ago

sylware 3y ago
Good news for my custom, plain and simple, C coded media player based on ffmpeg. I'll be able to view such streams, but... ... how I can be a contributor of such p2p stream without a big tech web engine? (I use only noscript/basic (x)html browsers). I could setup a "node" (should be plain and simple C coded) on my desktop computer, then from this node, I would extract the stream itself and watch it locally (I have a 800MBits uplink, and I know what IP diffserv with its ethernet translation is). If the specs/protocol stack are reasonable and not too much convoluted, I would even be able to code such node (based on ffmpeg, very probably). AND... if this p2p network is actually good and works IRL, do you really think the CDNs and streaming platforms will let it exist without a little bit of DDOS-ing...?

at_a_remove 3y ago

I wonder if there's a handy client and, if so, how sophisticated it might be.

sylware 3y ago

Cannot wait to see the "doc" independent of all streaming platforms... :)

rektide 3y ago

Yet another submission where WHIP & the WebRTC are conflated. This is due using http to stream video to another service which can actually do WebRTC. Still excellent still a huge win, but also a pretty big distion. Users still need considerably more to actually get online. Same conflation happened for ffmpeg getting WHIP. https://news.ycombinator.com/item?id=36130191 https://news.ycombinator.com/item?id=36130191

Sean-Der 3y ago
Sorry I might be confused, but `This is due using http to stream video to another service which can actually do WebRTC` I don’t think is right. WHIP is WebRTC signaling only. It just standardizes using a HTTP POST to exchange Offer/Answer. No media flows over HTTP.

sharts 3y ago

Nice