[HN Gopher] LiveKit - Open source, high performance WebRTC infra...
___________________________________________________________________
LiveKit - Open source, high performance WebRTC infrastructure
Author : simonpure
Score : 129 points
Date : 2022-05-20 13:25 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Sean-Der wrote:
| I am so impressed how quickly LiveKit has developed and become
| polished. If you missed it they wrote a really good article on it
| here[0]
|
| I also really love as a company how LiveKit operates. I work on
| an Open Source library they use (Pion). They contributed so much
| upstream and take an active part in the community. They also
| publicize that they are using it. It is great seeing people doing
| the 'right thing' succeed :)
|
| [0] https://blog.livekit.io/livekit-one-dot-zero/
| roshanj wrote:
| We've been building a live-streaming & remote operation system
| for drones using LiveKit. I've been extremely impressed at the
| speed they've delivered improvements and grateful of how
| supportive DZ & the LiveKit team have been of us. It's definitely
| the right choice if you're looking for a modern SFU system to
| run. Congrats on reaching 1.0!
| davidz wrote:
| Thanks Roshan!
| moron4hire wrote:
| Serious question: why does an SFU need TURN? Is it just because
| you already had centralized stream broadcasting and making it
| TURN compliant was low-hanging fruit?
| j1elo wrote:
| Technically an SFU doesn't need it. But clients connecting to
| the SFU will probably need it.
|
| Also having a TURN server allows for very restricted corporate
| scenarios, such as everybody connecting through a single, well
| known port (as Sean's S.O. reply mentions in the sibling
| comment).
|
| For example in OpenVidu (not trying to plug it here so won't
| put a link) a Coturn server is deployed, and TURN credentials
| are automatically shared with all clients (web browsers, mobile
| phones) so they can access the SFU through the Coturn instance,
| if needed. People are using this on very restricted networking
| setups for allowing connections between differently segmented
| networks, some of them not even connected to the internet.
| Sean-Der wrote:
| In some cases a TURN server is still required[0]
|
| Until ICE supports TLS/DTLS it is worth deploying. I hope to
| fix this in the near future though!
|
| [0]
| https://stackoverflow.com/questions/61287054/understanding-s...
| moron4hire wrote:
| I see, so the TURN server negotiates the access authorization
| (and provides a single connection point), but then the SFU
| handles the routing between peers.
|
| Is there a way to get a standard TURN server to reuse
| outbound streams for 3+ user chat? E.g. I have a CoTURN
| install that is strictly used for audio and while I'm not too
| concerned about bandwidth at my server, I'm very concerned
| about uplink bandwidth for users with asymmetric connections
| (which is practically all of them).
|
| I'm sorry to bug you here, but it's so hard to find anyone
| who actually knows much of anything about WebRTC who isn't
| just parroting stuff they read on Stack Overflow. Half the
| time I get the same, subtly-wrong answers about basic
| signaling, even when my question isn't even about signaling.
| Sean-Der wrote:
| Yea! TURN can just be the authorization/entry point into
| your network. The SFU is in charge of actually shuffling
| the packets between peers.
|
| You will need to use a SFU to reuse outbound streams
| unfortunately.
|
| Happy to help more on https://pion.ly/slack! I come back to
| HN once or twice a day, but will see your questions
| instantly. I am `Sean-Der` in `#pion`
| command_tab wrote:
| Related, check out OvenMediaEngine:
| https://github.com/AirenSoft/OvenMediaEngine
| Ironlink wrote:
| If I wanted to build a Twitch clone for internal social
| activities at my company, would this be a good tech stack for
| that or is WebRTC not the right fit?
| pavlov wrote:
| I don't know about LiveKit, but I work at Daily
| (https://www.daily.co) which uses WebRTC for client
| connections.
|
| You can definitely use Daily to build a Twitch clone and beyond
| -- we have a powerful API for custom layouts and graphics in
| live streams.
| imtringued wrote:
| You can do it with WebRTC just remember that it is meant for
| low latency video connections. The trade off is a higher
| bitrate and no caching.
| russ wrote:
| You certainly could, there are some folks in the community
| building Twitch-like livestreaming experiences with LiveKit.
| One of my teammates built a mobile livestreaming demo app,
| perhaps I can convince him to release the code. ;)
|
| Update: Given that this is for internal use at your company, a
| single LiveKit node should be perfectly fit to handle the scale
| you need.
| alexandargyurov wrote:
| Was a joy to use on a side-project I was working on. Worked great
| with Svelte. Deploying a local dev server is easy too.
| mwcampbell wrote:
| Would be nice to have a Rust client SDK that could be used across
| desktop platforms, but particularly on Windows. I suppose though
| that could involve some nasty build system wrangling, to embed
| Google's WebRTC library in a Rust crate.
| Sean-Der wrote:
| I think https://webrtc.rs/ is our best bet for this future. I
| am very optimistic about it. The security/memory safety aspect
| of it is just so important.
|
| So many important things are happening over WebRTC
| (telemedicine, remote control of dangerous machines...) I just
| would hate to see one of these C++ memory bugs have a negative
| impact.
| mwcampbell wrote:
| Do you think it would be practical to rewrite even the hard
| audio DSP stuff, like echo cancellation, in Rust? Or should
| webrtc-rs use bits and pieces of Google's WebRTC C++ library
| for that? I certainly see the benefits of not using the whole
| C++ library, with its threading model and all.
| russ wrote:
| It certainly would be nice! Having a common layer for signaling
| (whether Rust or C++), which could be used across client SDKs
| is something we're evaluating. You'd still need a (albeit
| thinner) platform-specific SDK for the final interface and to
| abstract away any quirks.
| mwcampbell wrote:
| I'd recommend Rust for your shared client core, even though
| for short-term practicality you probably have to keep using
| Google's C++ WebRTC library, because translating your
| existing high-level client code to safe Rust would be easier
| than translating it to reasonably safe C++.
|
| If you're interested in pursuing this, the best starting
| point I've found for using the WebRTC C++ library from Rust
| is this: https://github.com/arcas-io/libwebrtc So far it
| looks like it only works on Linux and Mac.
| russ wrote:
| Thanks for the pointer to that project, we'll take a look.
| =)
|
| On your recommendation of Rust over C++, is the thought to
| deal with the double-bridging (platform-sdk => rust =>
| libwebrtc) until webrtc.rs gets to a point where libwebrtc
| can be swapped out?
| mwcampbell wrote:
| Yeah, I'd do double-bridging for now. The Rust/C++
| bridging is pretty low-overhead IIUC, but getting it all
| to build and link together is probably a pain.
| davidz wrote:
| Arcas is fantastic! They are doing some really great work
| with WebRTC.
___________________________________________________________________
(page generated 2022-05-20 23:01 UTC)