7 ms·

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

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?
    - 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.
- 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.

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.
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.