Given the recent controversies surrounding Discord and the fact that the end user is a product of Twitch, I wonder if there is any “bare bone” solution to stream my gaming session to a friend who’s on Windows. I’d rather that they didn’t have to do anything except clicking on a link or perhaps installing a piece of software but with no need to do any configuration. From their perspective, it should "just work.
On my side
Should I set up a webserver into which I feed an OBS stream? Or can perhaps ffmpeg work as a server on it’s own?
I’m on Arch Linux, playing games on Steam, within dwm within X11.
On my friend’s side
No idea how a windows user is supposed to receive such a video feed.
Edit: text and voice chat, we’re considering Signal for.
TL; DR use Jami
You want something to stream low latency, don’t you? Honestly, that means peer to peer, not centralised (I. E streaming to a server which then streams to your friend). OBS will use large buffers (multiple seconds) that are then sent out to the server.
I would suggest using Jami. It’s peer to peer chat with peer to peer video and audio calls. It’s the simplest solution I’ve found. Matrix has MatrixRTC (or whatever they call it) but you will need the Element client and will need to activate RTC in the “labs”. Not sure if it’s in the stable build or the beta.
Signal can also stream peer to peer (webrtc like every other) but it compresses a lot and encrypts on top of it. You could have low latency but you will have visual artefacts and there’s no way to tweak the settings.
Peer to peer vs a server does not have significant latency difference. There is one, but not one universal enough that’d make latency the reason to choose the former in most cases.
It doesn’t. Streaming from OBS over WHIP is able to get down to about 300ms of latency, and that’s when watching via a server, rather than peer to peer.
The main source of streaming latency (the buffer you mention) happens when using the older HLS standard.
WHIP or WebRTC HTTP Ingestion Protocol (and the other end for clients, WHEP) allows software like Broadcast-box to be just as fast as conferencing screenshares in peer to peer video calls. Because it is the same tech.
MatrixRTC voice, video and screenshare is in element, comment and cinny. It does not need to be enabled in labs. Its main problem at the moment is the lack of system audio when sharing the screen.
OBS with Broadcast-box allows you to achieve real-time video sharing with audio, with full control of the video stream audio and quality thorough OBS’s recording and encoder settings. And to watch, your friends need no accounts or anything, they just open the broadcast-box link in a browser.
I wasn’t aware of WHIP, thank you. Last time researched this there was only LL-HLS which was terrible and when I tried Steam for streaming, it was using RTMP with a 6 second latency.
However, while broadcast box looks nice, it seems to require significant setup to stream.
I don’t know what OS OP is using but on Linux, you can start a video call with Jami (or anything really), then use qpwgraph to send the game audio to the calling application. 2 steps, start call, send game audio to call.
But it’s up to OP what they want to do. It’s been a while, but Jami might support sharing system audio now. Their feature list includes “media sharing” in the call features.
The qpwgraph workaround works in the matrix clients as well, but passing media audio into a WebRTC stream meant for voice is not ideal. Any decent client is likely to heavily filter out background audio (which with a game would be a lot of the ambient soundscape), and the audio would in some cases end up mono.
Broadcast-box is on the simpler side, if self hosting. If not, there is a public free-to-use instance here: https://b.siobud.com/