[HN Gopher] OBS merges WebRTC support
       ___________________________________________________________________
        
       OBS merges WebRTC support
        
       Author : Sean-Der
       Score  : 262 points
       Date   : 2023-06-10 18:07 UTC (4 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | seydor wrote:
       | 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
        
         | crazygringo wrote:
         | It has nothing to do with web standards, or the web at all.
         | 
         | Back in 2001 your computer was probably connected directly to
         | the internet over Ethernet with a dedicated IP address so the
         | simple setup worked fine.
         | 
         | But then Wi-Fi came out and people had routers at home and NAT
         | became the norm. This forced STUN/TURN.
         | 
         | It's entirely a networking issue, not a web issue. IPv6 could
         | have made NAT a thing of the past, but obviously it hasn't. But
         | firewalls are also the norm now in a way they weren't back in
         | 2001 because security has to be tighter now.
        
         | torginus wrote:
         | 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 wrote:
           | That's why they should have eaten the bullet: ipv6 and tcp,
           | only.
        
       | Eruntalon wrote:
       | [flagged]
        
       | prahladyeri wrote:
       | 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
        
         | andybak wrote:
         | I use ShareX and I use OBS - there doesn't seem to be a huge
         | overlap in functionality?
         | 
         | ShareX - screen capture and screen recording.
         | 
         | OBS - streaming (and lots of related functionality).
         | 
         | I'm guessing you were using OBS for screen recording - but
         | that's not really close to it's core feature set.
        
           | ehsankia wrote:
           | A lot of people use OBS for screen recording. I do think
           | ShareX is extremely limited unless you want to record
           | something super simple.
           | 
           | OBS' ability to compose a whole scene, dozens of different
           | capture methods, overlays, full audio mixer, transitions,
           | etc. It's the perfect place to record any sort of desktop-
           | based video. It's far far more than just "screen recording".
        
           | hsudhduhsh wrote:
           | i use obs exclusively for your sharex use case.
        
             | imtringued wrote:
             | I use the gnome screenshot widget.
        
         | pwython wrote:
         | I've been using OBS since it first came out (11 years ago?) on
         | just a 2012 MacBook. Never had a single issue.
        
         | paulryanrogers wrote:
         | Windows only. Still, good to have alternatives. OBS is nice in
         | that learning it means you can use it on 3 of the biggest
         | platforms, even if performance isn't top notch.
        
         | DJBunnies wrote:
         | Post your specs you dinosaur
        
         | jeroenhd wrote:
         | I find OBS not to be that heavy as long as your GPU does all
         | the work. A modern i3 would probably do fine if it has
         | QuickSync enabled and not too many extra filters and inputs at
         | the same time.
         | 
         | ShareX doesn't live stream as far as I know? Let alone offer
         | WebRTC?
        
         | prmoustache wrote:
         | obs works well for me on a decade old machine.
        
         | haunter wrote:
         | Use the GPU encoder not x264. x264 is very CPU heavy, even on
         | veryfast.
        
         | piperswe wrote:
         | The Ryzen 3 1300X is a low-end, nearly 6-year-old CPU. The Core
         | i5 2500K is a mid-range, _12-year-old_ CPU. It's a perfectly
         | reasonable minimum requirement.
        
         | mikece wrote:
         | 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 wrote:
         | 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 wrote:
           | > _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 OBS1 seems like it might be the
           | only tool that can do that. Is that not a good use for OBS?
           | 
           | 1 https://obsproject.com/forum/resources/source-record.1285/)
        
             | circuit10 wrote:
             | I guess they mean not _just_ a screen capture utility
        
             | lucideer wrote:
             | Sorry I should've been clearer: it can certainly be used to
             | capture your screen. It's just an extremely ancillary
             | subfeature.
        
           | gsich wrote:
           | It is.
        
             | lucideer wrote:
             | It can do screen capture. That doesn't make it a screen
             | capture utility. In the same way as Visual Studio is not a
             | note-taking app, blender3d is not a video editor and Excel
             | is not an IDE.
        
       | password4321 wrote:
       | Related (somewhat):
       | 
       |  _WebRTC support being added to FFmpeg_
       | 
       | https://news.ycombinator.com/item?id=36130191
       | 
       | 10 days ago
        
         | sylware wrote:
         | 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...?
        
       | Sean-Der wrote:
       | 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. The PR
       | to add WebRTC to OBS 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.
        
         | ehsankia wrote:
         | Woah, so if I understand this correctly, I can just put
         | whatever streamkey i want in OBS with
         | 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 wrote:
           | Yea exactly!
           | 
           | 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.
        
         | viraptor wrote:
         | > 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 wrote:
           | 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 wrote:
             | Ok, so it's more of a "direct connection" than "peer to
             | peer" scenario. That makes sense.
        
               | jraph wrote:
               | 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 wrote:
               | 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/
               | 
               | I have an example of WebRTC without signaling
               | 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!
        
               | eyegor wrote:
               | Since you seem familiar with it, do you think it's
               | possible to run a webrtc connection over http in a modern
               | browser? I tried for a while to make this work but I gave
               | up because it seemed like in js land it tries to use the
               | getUserMedia apis which aren't allowed in an insecure
               | context. The reason why I was trying was to stream audio
               | + data locally from a device that emits its own wifi
               | network (fully offline due to environment restrictions).
               | It seems dumb to have to serve invalid self signed certs
               | just to set up a webrtc ice handshake.
        
         | felipellrocha wrote:
         | > 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?
        
           | numpad0 wrote:
           | It just means the overhead is smaller for the feature set it
           | offers. It's not faster than bare MJPEG over UDP, but not way
           | slower than that either.
        
           | Sean-Der wrote:
           | It is pretty easy to get a one way trip time for packets that
           | is sub-second! You see it with conferencing and other real-
           | time communication things.
           | 
           | If you are curious on the 'how' of WebRTC I wrote a Free/Open
           | Source book that goes into the details
           | https://webrtcforthecurious.com/. Happy to answer any
           | particular questions you have.
        
             | evv wrote:
             | You are a legend.
        
             | felipellrocha wrote:
             | Man... I've been up all night, traveling all day, trying to
             | adjust to the new timezone. Boy, I swear I read "sub-
             | millisecond". Lol. Makes sense :) Thanks for the resource!
        
             | beebeepka wrote:
             | Bookmarked.
             | 
             | I added WebRTC support (audio, video, chat) to my already
             | existing application a couple of years ago and felt the
             | technology wasn't exactly ready for primetime. To me, it
             | felt like the out of the box developer experience wasn't
             | exactly great.
             | 
             | I am only saying this because I got to see exactly how much
             | effort is required to get things going. Your work is
             | greatly appreciated
        
           | gruez wrote:
           | Why shouldn't it be possible? Screen share on a Zoom/Teams
           | meeting is basically a stream with sub-second latency.
        
           | hsudhduhsh wrote:
           | 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 wrote:
             | I have less latency to California than most Bluetooth
             | headsets have to your ears.
        
           | Karrot_Kream wrote:
           | 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 wrote:
             | SFU?
        
               | Karrot_Kream wrote:
               | 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.
        
         | EGreg wrote:
         | 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?
        
           | jeroenhd wrote:
           | 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-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).
        
             | weinzierl wrote:
             | What do you mean by Twitch's bandwidth cap? Obviously
             | Twitch supports more than 100 viewers, so is this an
             | upstream cap from the streamer or a downstream per user cap
             | or something different all together.
             | 
             | A glace over Twitch's broadcasting guidelines was not
             | enlightening, but I'm clueless in these matters.
        
               | ripdog wrote:
               | He means the cap on the bitrate of the video that twitch
               | will ingest. Twitch will then send this video to any
               | number of viewers, as you say.
        
             | martinald wrote:
             | _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.
        
               | jrockway wrote:
               | GPON is typically shared bandwidth; 2.5Gbps for n
               | customers (that could be an entire building, or the 4
               | houses adjacent to a box in the backyard, etc.)
               | 
               | More advanced fiber networks split bandwidth based on
               | frequency ("color") instead of giving each ONT a time
               | slot based on the current network capacity. But
               | basically, if you're uploading at 1Gbps, that is fine
               | until 1.5 more neighbors decide to do the same thing.
               | It's rare. When I worked at Google Fiber we kept an eye
               | on PON utilization and there was never a case where a
               | customer couldn't get the requested bandwidth. We even
               | had customers that maxed out 1Gbps/1Gbps 24/7 in an
               | attempt to get banned or something, but of course we
               | wouldn't ban you for that. We did worry about PON
               | capacity and had some tech ready to go in case we ever
               | needed to switch to truly dedicated per-customer gigabit
               | connections.
               | 
               | At another ISP I worked at, our marketing material
               | described the 1Gbps GPON-based link as "dedicated", but
               | many customers noticed it was shared. It would slow down
               | during peak business hours, and then get fast when other
               | people in the building went home from work. We removed
               | the term "dedicated" from our marketing. A political
               | battle that I paid dearly for, but hey, they still exist
               | and didn't get sued into oblivion by the FTC, so that's
               | nice. (We also sold frequency-multiplexed 10Gbps circuits
               | that really were dedicated... I suppose until our uplink
               | to our ISP was saturated. I think we had 100Gbps transit
               | and that never happened. But yeah, there is no such thing
               | as dedicated unless you are physically plugged into the
               | network that you want to reach. The Internet tries its
               | best.)
        
               | martinald wrote:
               | I know that GPON is shared; but as you say it's rarely
               | the 'weak link'. Regardless, even if it was, it's much
               | more likely that the downstream would be saturated on the
               | gpon level vs the upstream - consumer ISPs are much more
               | downstream heavy than upstream heavy, so I have no idea
               | what the parent post means when he says that its hard to
               | saturated gigabit uplink on consumer connections. It's
               | the opposite if anything.
        
               | numpad0 wrote:
               | It's not about bandwidth inside the AS, but about fiber
               | peering from ISP datacenters "to the Internet". I don't
               | have anyone's internal informations but that must cost
               | 10-100x more than $35/Gbps/month. Residential internet is
               | gym membership model, a best effort offering. Resources
               | are always heavily over-committed based on typical use
               | cases of groups of average users.
        
               | bluefirebrand wrote:
               | > 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 wrote:
               | 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.
        
           | charcircuit wrote:
           | 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 wrote:
             | 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?
        
               | grogenaut wrote:
               | How can a webserver serve 10k people at once?
        
               | charcircuit wrote:
               | 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 wrote:
               | 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 wrote:
               | How are they doing it is the question? What's the set up?
        
               | fidotron wrote:
               | 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 wrote:
               | 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-
               | arc...
        
               | fidotron wrote:
               | 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 wrote:
               | How does WebRTC know what resolution to send? Or does it
               | always send the original resolution?
        
               | fidotron wrote:
               | 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.
        
               | [deleted]
        
         | sitkack wrote:
         | 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 wrote:
           | 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 wrote:
           | 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 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...
        
             | sitkack wrote:
             | Thanks for the response, I'll take a look. I really
             | appreciate how much focus you put into this project. I
             | think it does good for the world.
        
             | prox wrote:
             | 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 wrote:
               | 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"
        
               | Sean-Der wrote:
               | That was my hope for Broadcast Box! Mind checking it out
               | and telling me what you think?
               | 
               | It has a docker image so you should be able to run a
               | 'streaming site' with just a few commands :)
        
               | prox wrote:
               | What if you create extra facilities on a unified website?
               | I would pay for that. Maybe sub functions, chat functions
               | and so on. You need that for more discoverability I
               | think.
        
       | at_a_remove wrote:
       | I wonder if there's a handy client and, if so, how sophisticated
       | it might be.
        
       | nubinetwork wrote:
       | 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 wrote:
         | 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 wrote:
         | 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
        
       | mikece wrote:
       | 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 wrote:
         | 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
        
         | Sean-Der wrote:
         | 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 wrote:
           | > 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 wrote:
           | 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 wrote:
       | Nice, but curious, why use char* so much in a c++ project?
        
         | mackal wrote:
         | 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
         | ...
        
       ___________________________________________________________________
       (page generated 2023-06-10 23:00 UTC)