I've played local multiplayer games over parsec (https://parsec.app/), it works great and is pretty much turnkey

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.

Arcade is like a quick match menu for finding a game to play.

You can share any screen or desktop from the main app and have friends connect

Parsec looks great, but I'd be grateful for metrics (bc who knows what "low-latency" really means).

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:

   ffplay -fflags nobuffer -loglevel verbose rtmp://my-servers-ip-address/live/test

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)

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

Twitch has a low latency mode https://help.twitch.tv/s/article/low-latency-video?language=...

The latency on twitch has been around 4 seconds or 30 seconds. I believe their low-latency doesn’t get quite close to being nu able to collaborate.

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

Why do you need such low latency for live streaming? For the majority of cases 10s latency does not really matter.

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.

We use Discord with my friends for Jackbox, it works amazingly well, even with 10 persons together.

Then you require a video conference solution not a live streaming one. Similar but not the same.

edit: Why am I down voted? A live stream is a broadcast, a conference is an interaction.

Because they said that they tried it and it hasn't worked well.

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.

[1] https://www.jackboxgames.com/how-to-play-jackbox-games-with-...

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

Like I said, neither Jitsi nor Google Meet had working audio and both were at like 5 fps.

In the end they used a conference app, just one that seems to have better quality.

Interactivity with viewers.

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.

So which experince are you talking about?

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.

I never said he does not need it and you are projecting some tone on my question that is only in your head.

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.

Have you tried Discords GoLive sharing?

That requires that viewers use Discord, which may cause problems for some, even though Discord is huge anymore.

The posted solution requires only a web browser for the viewer, and OBS for the streamer.

Yup that was the point :) In the future configuration of the server will become easier as well!