Show HN: Lightspeed – subsecond, open source, self hosted stream from OBS
github.com
github.com
This has been a super fun project which has taught me more than any other project I have done. It uses Rust, Go and React and can be deployed fairly easily on a very lightweight server. For example, I have been doing my test streams on a $5 Digital Ocean droplet and the CPU usage is at around 20%. Granted not a lot of people are watching however it is more lightweight than a solution such as Janus.
The point of this project is twofold. First I wanted to learn more about WebRTC and real-time communication in general. Second, I wanted to provide a platform where people can setup their own little live-stream environment. Maybe you just want a place where you and some friends can hang out or you are sick of the main-stream platforms.
Anyhow as of writing this post it is v0.1.0 and considered an MVP release. In the coming months I (and hopefully some of you :)) will be adding more features and trying to flesh this out into as much of a full featured platform as possible. Feel free to take a look at the repo and let me know what you all think :)
[1] Open Broadcast Software (OBS): https://obsproject.com/
Would it ever be possible to route two stream via different paths to the client and let the client just accept the first packet from either and drop the other in order to add some redundancy to delivery?
A diagram of the setup on your page would be helpful...
Sometimes network paths die. This could be a dodgy router in a third party network that drops streams for 150ms at a time, or a bgp recalculation that knocks it out for maybe a minute or so.
In both cases you need to have multiple routes to keep your latency low.
As an aside, I’ve noticed you’re building out your own stream protocol stack (FTL/LightSpeed). What’s the reasoning there? Seems slightly inconvenient to have to “hack” OBS to make the output stream work. Will FTL support be merged into OBS in the future?
If you’re just trying to avoid the latency of RTMP then I might suggest considering the existing SRT protocol[1]. It’s been open source for a while and is well-established(native support in OBS core and optional in FFMPEG). Seems to already solve a lot of the transport-level stuff that you’re working on with FTL.
[1] Secure Reliable Transport: https://github.com/Haivision/srt
Looking forward to tinkering with this!
I wanted to try this, even made a docker config and only then realized I can't stream to it from Archlinux.
Having recently attempted to use SRT for an event's backend restreaming stack, the low latency was nice but it's a pain in the ass. It's really not designed for links where latency isn't known and consistent. You have to bake an expected latency amount into initial protocol negotiation or you'll end up with problems, and OBS' support is quite poor (failure to establish a connection for whatever reason is likely to freeze it up completely, it sucks up a lot of cpu vs. rtmp, etc).
And the other end of the stack is either pretty immature and kind of wonky (haivision's own software, srt-live-server) or requires you to pay to use it or is very closed source.
WebRTC of some sort is definitely the future of this, imo. Even if the stack kind of sucks right now the results are fabulous (discord's video streaming for eg. is webrtc based and is easily the lowest latency free screen sharing I've seen outside share-my-desktop stuff like parsec or rdp).
It looks like this uses the already-built-into-obs support for the webrtc-based ftl protocol mixer used and microsoft killed. That's actually really clever and honestly I think this is far more appealing than SRT.
* werift (Typescript)
* Pion (Golang)
* aiortc (Python)
* KVS WebRTC (mbedtls, embedded C)
* GStreamer's webrtcbin
* rawrtc (C++)
* webrtc-rs (Rust)
* libwebrtc Google’s Implementation (C++)
RIST adds nack based retransmissions to decades old RTP and has multiple implementations.
Hoping to see OP answer this and in particular what I would like to see them comment on is how they divide their codebase between these two languages. Which parts are being implemented in which of those languages and why.
Personally a huge proponent of Rust.
The Rust Lightspeed-ingest[2] server is also ~500 lines of code, and primarily handshakes the FTL protocol used to communicate with OBS.
There is a Pion port to rust[3] that is in progress. I am not sure the state of this work. Pion is used quite extensively by many many projects; I'm not sure if the rust webrtc-rs port has any notable users yet. As I began by saying, I expect the trustability & extensiveness of Pion is what lead to lightspeed-webrtc being written in Go.
[1] https://pion.ly/
There are, or were, no good turnkey solutions for this. Twitch and Youtube have 5-10s latency, which is often not good enough. Mixer promised (and presumably delivered) ~1s latency using the FTL protocol you use, but they had a wait list of a couple of days or weeks, and of course now, they don't exist anymore. Even Steam Play Together, ostensibly built for this purpose, wasn't low latency enough in my limited experience (this really surprised me, so maybe I'm doing it wrong).
The easiest solution, use the share desktop function of whatever video conference tool, almost works, but they universally seemed reduce the frame rate, which is ok for presentations but unsuitable for games (also, no audio). My solution was to output OBS to a virtual webcam device and use Jitsi Meet. A bit roundabout, but it worked wonderfully.
Ideally, I'd forgo the DO droplet, and just run everything locally. 20% of a small droplet is even less of a modern desktop computer's CPU. Which leaves upload bandwidth for broadcast, which depends on your connection and how many people you need to be able to stream to.
You can share any screen or desktop from the main app and have friends connect
The posted solution requires only a web browser for the viewer, and OBS for the streamer.
edit: Why am I down voted? A live stream is a broadcast, a conference is an interaction.
Other online games wouldn't fair so well but the dropped frame rate in Jackbox Party games does not hamper the playability of their games at all.
Maybe Zoom and MS Teams offer(ed) a better fidelity. For one thing, Zoom lets you share desktop audio along with the screen. In fact, apparently these days, Jitsi can do that too, that definitely wasn't possible when I tried it early last year. At that time, at least, the experience OBS -> Jitsi was definitely much better than just Jitsi. (And note that all of this was in Linux.)
I think you're being rather unfavourable there. The Jackbox developers have been pretty responsive listening to user feedback in the past. For example Linux support was added after several requests on Steam forums. They've also added other features like subtitles specifically for streaming via video conferencing solutions. So if Zoom / Teams / etc didn't work well then you can bet they'd have posted another workaround and/or a game patch since the alternative is they'd lose a lot of potential business in 2020.
As I'd said, I'd used it fine over both Zoom and Teams (multiple times on both in fact) and the only reason I even bought Jackbox Party games was because several different work colleagues (I think it might have been 3 different people) recommended it to me after they had played their own games (individually) over Zoom and other conferencing solutions.
I don't have any experience with Jitsi so maybe the issues you were having were Jitsi specific? Maybe, being a techie, Jitsi was already "good enough" but you thought you could improve upon it a little and ended up over-engineering a solution? (we've all fallen into that trap -- when you spend your entire life building enterprise solutions it's sometimes hard to take a step back. Particularly when it's something as fun as OBS). Or maybe there was some issue with Linux? All I know is that myself and everyone I know has had zero issues hosting using Jackbox's recommended approach.
Also in that guide was Discord and Steam Remote Play. It's a surprisingly technical guide (but in a good way) considering the average audience that might read it. It feels to me that some genuine thought did go into that document.
> Maybe Zoom and MS Teams offer(ed) a better fidelity.
Maybe. Anecdotally I've not had any issues with Zoom whereas Google Meets often feels like it's both heavier on the CPU and feeds seem worse. However that's running Meets on Firefox (Linux), it might perform better in Chrome.
[1] https://www.jackboxgames.com/how-to-play-jackbox-games-with-...
The best streaming experience for both streamer and viewers is when they can interact, and any latency over 500ms or so makes that a true challenge if you're trying to have a conversation where context is important.
Being an introvert that doesn't like it when people pay attention to them at all for any reason, I haven't really experienced this, but that's what everyone says.
So which experince are you talking about?
CPU usage on the streaming PC does not increase latency unless the PC is severely under spec. CPU usage increases CPU usage. That's it. Encoding usually happens on a GPU, and scene composition happens on the CPU, which is either a zero-copy routine or a very fast memcpy.
My point is that from what you're saying, it seems clear to me that you are not aware of just how good WebRTC is at this kind of thing.
On the client side you have two options:
1. For low-latency game streaming, I would suggest watching through the RTMP stream. The RTMP module for nginx will re-broadcast your RTMP stream to all the clients that connect. I was able to get a latency of around 1 second by watching through:
ffplay -fflags nobuffer -loglevel verbose rtmp://my-servers-ip-address/live/test
2. HLS/Dash. The nginx RTMP module will also expose the video stream as HLS/Dash which is just cutting the stream up into files and serving them over http. Personally I set my segment size to 1 second and my playlist size to 4 seconds. Through this I get approximately a 4-second latency. Not great for competitive multiplayer games like Jackbox but if you're playing something like a world building game with friends then its acceptable. The real benefit to HLS/Dash is you can easily watch it through an html5 web video player or even a chromecast[2].
Bits you can add on top:
- I put my HLS/Dash directories in a tmpfs mount for speed and reduced wear on the drives
- I put the nginx stream module in front of my rtmp module so that it can handle TLS (making it RTMPS)
[1] https://github.com/arut/nginx-rtmp-module
On FreeBSD it was just a checkbox in the nginx port, so the work involved may vary by distro.
[2] I haven't attempted to play the RTMP stream through chromecast so for all I know, that might be supported too. All I've tested so far on chromecast is an HLS stream using the "castnow" CLI program. The Shaka player, which is a web player, will support chromecasting an HLS stream from your browser but I've only tested their demo videos, not my personal streams, and I had to use official google chrome, not chromium, but it worked on both android and linux.
I've had good experience with Steam Play Together, mostly playing Unrailed (a hectic game in the style of Overcooked). I definitely forget about the remote connection while playing. We were 1000 km apart, but had quite a good connection (100 Mbit, 15-20 ms ping).
Unfortunately, with Mixer's death, I don't think there are any major turnkey players left with low latency sub-second streaming. I'd probably use Discord as a primary alternative which uses WebRTC with Discord's servers in-between.
If your home connection has the bandwidth to support the load of multiple users, a service that does direct P2P like Parsec will probably give the best performance.
Have you tried streaming via Tor? Is it possible to achieve streaming via Tor even if subsecond delay can't be achieved?
I hand't heard of FTL before. Apparently it was a protocol used in Microsoft's now-defunct game-streaming service, Mixer. I found some discussion of the various streaming protocols here[1], which included some description of FTL.
I guess it comes down to latency. That would still have left SRT on the table, yes?
Great project. Such a key area of connectivity for us all. So glad you did this. Thanks.
It's a topic I'm interested in. Mainly to see examples (and learn from them) about when people prefer lax licenses on the style of "do what you want with this, including a closed-source proprietary business" (MIT, Apache) which has allowed in the past that big Co's. benefit from it without giving back (lots of cases in HN), vs. strong copyleft "do what you want except closed-source proprietary stuff" style (generally speaking, the GPL family -- EDIT: I know that this, being mainly a server-side thing, would be more affected by AGPL than by GPL. Bear with me.).
If there are no business / commercialization intentions in the foreseeable future, would it make sense to use a GPL license (one of them) to build a strong open-source community?
Or it doesn't matter in practice? (i.e. it doesn't really affect the chances of building a good and strong developer community)
GPL restricts what users can do, and thus restricts freedom in my eyes.
Not sure why anyone would care but it seemed like a good time to explain my thoughts on that while agreeing with you.
This kind of thing has been needed for some time, so thank you for creating it.
Restricting the freedom to use your work to restrict others' freedom, is not nearly so onerous or hypocritical as GPL bemoaners try to characterize it.
I feel absolutely zero sympathy for the argument.
A MIT or Apache license might detract contributors, because essentially these licenses say "your contribution is OSS today, but it might end up resulting as unintended free labor that helps build a commercial product of which you won't be part of".
However some see GPL licenses as a guarantee that external contributions are actually contributions to the overall Open-Source community as a whole, because they cannot be turned into other non-OSS product without explicit permission of all people who built it.
So yes, copyleft is more restrictive than non-copyleft. But only in the subtle sense of ensuring that no further restrictions will get added by any third party, ever. Which is a strong promise that should encourage contributions.
Ultimately, my objective is to learn if this theory matches the practice.
Contributions to non-copyleft OSS licenses _are_ actual contributions to the open source community as a whole.
There's nothing preventing your GPL'd project from being used to make a commercial product that you are not a part of either. You're talking about enforcing perpetual conditions on the future of the product/license for your free labor. This is the reason why projects like MAME have contributor agreements now.
Even if through some process the license changes in the future, your contributions were still to an open source license and that version of the code will remain open forever.
I haven't seen anyone discouraged from contributing to OSS-licensed projects that are not GPL unless they are an extreme ideologue. I myself generally prefer to license my work with something like MIT or Apache (read: the ISC license, generally) and that choice is absolutely fine.
Copyright law does exactly this. The role of the GPL is to carve out explicit exceptions to the "you can't copy this" rights granted by copyright law.
They are not the same.
Also, more relevant to the discussion I was responding to, the GPL license doesn't allow re-licensing without consent (or a pre-arranged copyright assignment - a contributor's agreement). And it's copyright law which enforces this.
Most people don't want to work with random contributors who wish to hold a gun to their heads in perpetuity.
An aside, that's an awfully violent visual for discussing ownership of code.
This article gives a nice description of the differences: https://opensource.com/article/18/3/cla-vs-dco-whats-differe...
So even if theoretically the most aggressive licenses still allow for commercialization, the practical effect is that commercializing a copyleft codebase won't travel too far on its own as a business plan.
This has been discussed a lot of times in HN, and the conclusion always is something on the lines of "don't do copyleft if you want to have any aspirations of commercialization on the software itself as opposed to peripheral elements such as support services or similar".
Red Hat was acquired for $34 Billion.
It really depends on what you're selling and how good your product is.
> "don't do copyleft if you want to have any aspirations of commercialization on the software itself as opposed to peripheral elements such as support services or similar"
Cop out argument. This comes from the same people who do split licenses that spit in the face of the spirit of OSS. It's people who want all of the benefits of writing OSS (outside contribution, growth in use of your product, less investment in sales) but none of the risks (someone else using what you offer for free and having a better product than you). It's purely anti-competitive.
Turns out that Linux is a good product that needs a lot of stewardship and support that's worth paying for.
There's also hundreds of thousands of software developers and consultancies offering their services that make use of GPL'd (and other OSS-licensed) code. Probably 90% of this board is selling their services/labor of GPL'd projects. It's been my whole career.
No, what it sounds like is we're talking about people who want to write OSS but also want ownership and exclusive rights to make money off of it. My argument there is pound sand.
No idea about Suse.
In any case, even if they are great success examples, these can be counted on the fingers of one hand... so I'd say the sample size is not precisely "enough", not at least to prove a point.
EDIT: (reply to an edited part of the comment)
> what it sounds like is we're talking about people who want to write OSS but also want ownership and exclusive rights to make money off of it
I agree. On the other hand, most of the OSS that exists is created by such people, and what do we prefer? Idealistic but non-existing OSS software? or compromised but existing and useful OSS software? That's the question that I feel is behind all the conversations about this topic.
You miscategorize Canonical like it's some vanity project. Even vanity projects can be profitable enterprises! Look at Koenigsegg cars! They're literally a millionaire's vanity project that is a profitable enterprise employing hundreds of people.
> I agree. On the other hand, most of the OSS that exists is created by such people, and what do we prefer? Idealistic but non-existing OSS software? or compromised but existing and useful OSS software? That's the question that I feel is behind all the conversations about this topic.
Free software has been around since the 80s, at this point. With or without the GPL. It turns out that there are many, many successful products and businesses that use other OSS licenses. I don't think we're in any danger of people with our skillsets not being able to eat. We're basically all potential millionaires.
The GPL is _not_ the only option available. Heck, Apache is absurdly popular and the bedrock of many enterprises...
Well, that's a good take. You're right of course: the exact version of the codebase you contributed to, was licensed as OSS and it will always stay like that.
So yes, copyleft is more about providing guarantees about the future, while non-copyleft can only provide guarantees about the present.
I think this way of putting it is clearer than my previous way of saying it. Thanks for bringing up this point of view.
> This is the reason why projects like MAME have contributor agreements now.
Hence articles such as [1] and [2], which have been posted in HN before, albeit with pretty much zero conversation.
Still, just like I'm interested in the topic of OSS licenses and the thought process of people who choose them for their projects, I find also interesting the matter about CLAs and whether to go on with one or instead opting to use a DCO [3], which some well known OSS projects have preferred in the past: [4], [5].
[1]: Why CLAs aren't good for open source -- https://opensource.com/article/19/2/cla-problems
[2]: Why you probably shouldn’t add a CLA to your open source project -- https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-...
[3]: CLA vs. DCO: What's the difference? -- https://opensource.com/article/18/3/cla-vs-dco-whats-differe...
[4]: (GitLab) We're switching to a DCO for source code contributions -- https://about.gitlab.com/blog/2017/11/01/gitlab-switches-to-...
[5]: Helm Moves To DCO -- https://helm.sh/blog/helm-dco/
GPL ensures the code is freely available at all times, and anyone can use it, change it, distribute it but not take it away or restrict access to it.
From the code pov, MIT/Apache is freedom to take away and restrict access.
A developer is the "user"? MIT is freer for the dev, but the dev is free to restrict the end-user.
End-users are the users? GPL restricts developers from closing the source, empowering end users to become developers too.
> It is absolutely essential to permit users who wish to help each other to share their bug fixes and improvements with other users.
https://www.gnu.org/licenses/gpl-faq.en.html#WhyDoesTheGPLPe...
> GPL restricts what users can do, and thus restricts freedom in my eyes.
A few sibling commenters have already rebutted, but to add to that, a way of looking at this is that all licences necessarily restrict users (with the possible/arguable exception of things like CC0).
The difference with GPL vs MIT is that MIT gives users the "freedom" to further restrict other users in future, whereas GPL restricts users from ever further restricting other users
As I said, I'm not trying to push for this or that license, just want to have a perspective of the choice for new OSS projects.
Mostly the usual lesson is that authors typically don't really think through much about the licensing choice when they are hyped about an upcoming first release. Technical concerns are, understandably, what gets most attention at the beginning. Your position is the most common one I've found for small-ish projects.
I ended up with this hack: https://i.imgur.com/jDeMxly.png
Redirect the "Record" button of obs to make ffmpeg output to an http endpoint, which is a small server that just forwards any bytes it receives to connected consumers. They can then play it back with
ffplay -fflags nobuffer -flags low_delay -framedrop -strict experimental https://stream.server/lawl
Will definitely have to give this a try over my hack.
Don't expect much. I threw this entire thing together as quickly and lazily as possible.
If you want casual people to use this, I would look into simplifying the setup. Either by providing compiled binaries instead of having to set up go, rust etc oneself. Or by containerizing something.
I get that the maintainer has put a lot of work into this and wants to try and monetize some part which is hard when OBS is GPL, but depending on a binary which is nigh-on impossible to build and then charging for it on your website just feels a bit of a shitty way to do it.
What is the relationship between viewers and CPU load? I assume it is not linear? And does it do any sort of bandwidth optimization or is the outbound bandwidth stream size times number of users?
In other words, how many viewers do you think a single DO droplet could handle?
A simple switch is fine in this case, no overlays or anything
I've seen these apps on iOS though
Broadcast the camera: https://apps.apple.com/us/app/ndi-hx-camera/id1477266080
Broadcast the screen: https://apps.apple.com/us/app/ndi-hx-capture/id1501247823
I'm sure Android etc have similar. NDI is (more closely related to?) a protocol rather than a program though, there's bound to be something that speaks it for what you need
you'd have each of your different origins stream to their own private FTL paths, then in your OBS you'd create media sources from each of those paths then push your final, mixed stream to the public FTL path.
Incidentally - I met the the producer of the podcast "moneypot" on the plane a few days ago and we talked a ton - I asked about how would one get into podcasting/streaming if they havent yet - and she mentioned some great resources - I cant recall them off the top of my head - Ill have to ping her and get them again - but this is something I am going to look into learning during this pandowntime.
If you have resources to point at - that would be appreciated.
THanks for this though.
We usually use Discord's share screen feature, but having more options are always nice, and I assume I can up the resolution/bitrate as I need since it's based on an OBS stream.
Is it possible for a viewer of the stream to send it to a Chromecast?