Awesome! I was looking for something like this when trying to play a local multiplayer game via the Internet in an early lockdown.
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.
Yes, I forgot about Parsec, that's a good suggestion. I remember trying it, and not getting it to do what I want, unfortunately I don't remember why. I think I was stuck in the "Arcade", when all I wanted was to share my desktop or one window. It certainly looks like exactly what I was looking for.
In home streaming with Parsec for me with a MoCA/Ethernet connection typically has 1-2ms of network latency. Over wifi in-home is more, closer to 20-30ms with a mediocre laptop wifi card. Playing online with my brother who lives 35 miles away using an Ethernet connection I typically see 15-25ms latency, not much worse than a 'meh' bluetooth controller. It's likely worth noting that my brother and I both have the same cable internet provider, but we also sometimes play with my brother-in-law who lives another 40 miles from me (~60 miles from my brother) and we can all play games like Streets of Rogue together from my brother's PC without issue.
Wow, that is better than I'd hoped! Thanks so much for your response! (I know it's just an anecdote, but bc I'm looking to see what it's perf limits might be, even one data point like this is very helpful.)
> 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).
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).
I have a pretty low-latency setup for that but it wasn't completely turnkey. First you set up nginx with the rtmp module[1]. Then you can use OBS to stream your desktop to the RTMP server. I set OBS to send a keyframe every 1 second.
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:
I would expect better latency from a webrtc solution like Lightspeed but 1 second latency is pretty good for only having to install nginx.
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)
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 confirm that Mixer delivered on the sub-second latency claims. As far as I know, FTL's performance is in line with WebRTC's performance. As long as the servers in-between are fast, a good WebRTC implementation should match it.
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.
From my experience it largely depends on the stream - for some I can easily get <2 seconds, others will be >10s. I'm not sure what causes this difference (ingest server?).
We were playing the Jackbox series of games together, the other folks were participating in the game with their phones. There are various minigames with 5-50 second timers, so 10s latency is a lot. Some of the games have a special streaming mode which extends the timers, but not all of them and it's best played with regular timers anyway. Obviously for true action games, you absolutely need sub-second latency, preferably <100ms.
Discord mostly works for my friend group to play Jackbox games, though sometimes it's still noticeably slow, so OP's project is definitely an improvement.
Except for Jackbox Party games it's by far the best fit. It's even the recommended way to play online by Jackbox themselves and I've hosted Jackbox via both Zoom and MS Teams and it worked perfectly fine that way.
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.
They recommend doing it that way, because what else are they going to do, post a tutorial on how to do it via OBS? I don't think so.
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.)
You scoff but they did link to a tutorial on how to do it via OBS in their guide[1]. They just made video conferencing the first suggestion.
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.
> They recommend doing it that way, because what else are they going to do, post a tutorial on how to do it via OBS? I don't think so.
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.
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.
There is no realtime interaction on stream anyway if you have more than a handful active chatter. And lag is high by default if the streamer is doing more than just chatting, like playing a game, building some stoff or reacting to a video.
I don't think you know just how low latency WebRTC is.
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.
I hardly ever see use cases for live streaming where's latency doesn't matter... the only one that comes to mind is non-interactive television? But this is the Internet and people usually want live responses and chat with the audience... the difference between even two seconds of latency and subsecond latency for this fundamentally changes how the audience interacts with you.
I'll bite. I play D&D remotely with my friends. I need to be able to have low latency voice and video communication, but I also need control over the audio codec and bit rate. Zoom and other video conferencing solutions use codecs optimized for voice, which makes music and sound effects sound like a Himalayan AM radio broadcast. Twitch and Youtube give me control over the video and audio quality, but the latency is 5+ seconds even on low latency mode. I tried running voice over zoom and video and music over youtube, but then drawing on the map is 5+ seconds out of sync with me saying "look here".
When you are in voice with (some of) your viewers having a 10s delay is shit for everyone. A lower delay is just a better experience, for any kind of viewer input. That aside, it's easily possible so this whole "why do you want this, you don't need this" smacks of apple tech support - it's nice that you don't need it, but evidently you are not the only use-case on earth.
This is patently gaslighting. It is on me to try to read you in a positive light and it is on you to write language that supports what you are thinking.
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.