Self-Hosted Live Streaming

Throughout the pandemic, I’ve been mostly stuck at home—for at least a good six months—without being able to hang out with my friends. As such, we would spend a lot of time talking on discords, watching movies, playing games like Minecraft, basically doing all our activities online.

And one of the activities that we enjoyed the most was movie watching. Sure, we could use discord screen sharing or Teleparty for Netflix. But discord screen sharing isn’t as performant, i.e, stuttering and a smeary mess, whereas Teleparty is a little “difficult” to use.

_

The ideal solution would be something like a personal Twitch, but with better latency, and most importantly, free.

_

Something like Twitch is easy as all my friends have to do is just open up a link. Easy.

So, What do I want?

I’ve set out on looking for solutions that would allow me to create my own self-hosted live streaming platform, and it had to meet specific requirements.

I needed something that would allow me to use OBS. This is because OBS offers much flexibility to what I can show on stream. I could screen share, stream Minecraft, play JackBox, watch movies, have a PowerPoint night, etc. The possibilities are endless!

Now, you might ask, why self-host? Well, I don’t want to pay for Discord Nitro just for slightly better quality, and using Twitch/Youtube would get me DMCA-ed to hell and back. Also, what’s the fun if I were to go these routes! I intend this to be for private use only — not for commercial purposes.

And also I already have the hardware and network resources already so…yeah. One more thing, ideally I hope to be able to host everything on my Raspberry Pi 4. (unfortunately my old Pi2 is just way too slow for this)

Protocols.

Before I show you what solutions are out there, I feel it essential that we understand the different protocols when it comes to live streaming and the different purpose they serve. This will be a brief overview and by no means comprehensive but should give you an idea of how to pick the best protocol for your needs.

RTMP, FTL & SRT are the protocols used between OBS and the streaming server, whereas HLS, DASH, and WebRTC are used between server and client. I will provide links for further readings if you’re interested in learning more.

RTMP	The most commonly used protocol with alright latency. Unfortunately, with RTMP you can’t transmit directly to client as that would require Adobe Flash, which died millennial ago.
FTL	Developed by Microsoft for their Mixer platform, designed to be extremely low-latency. Unfortunately, Mixer died and the protocol never really gained much traction.
SRT	Designed to be a replacement for RTMP, it promises low latency and better performance/reliability for networks across long distances. Fairly new still, but seems like a worthy replacement of RTMP.
HLS	Developed by Apple, it works by splitting video stream into a few seconds long segments and letting the client stitch them together into one continuous stream. This allows for much better resiliency towards unstable internet connections and has support for scrubbing.
DASH	Works somewhat similarly to HLS, with slightly more features, but has poor support by Apple devices. However, DASH also has a low-latency variant which slightly improves the latency to around 5 seconds from my testing.
WebRTC	Work across UDP, it has very low latency. However, there’s no support for scrubbing and is also somewhat sensitive to poor connections.

As my main goal is low latency, I had to look for solutions that primarily use WebRTC for client-side delivery instead of HLS or DASH (even with the LL variants). All of the protocols provide similar stream quality for most intents and purposes.

https://owncast.online/

This was the first project that I stumbled across, very promising at the start. However, I was still very new to this whole live streaming thing, and I barely knew the different protocols used.

Owncast is an open source, self-hosted, decentralized, single user live video streaming and chat server for running your own live streams similar in style to the large mainstream options. It offers complete ownership over your content, interface, moderation and audience.

https://github.com/owncast/owncast

Overview

OwnCast looks to be a lot more like Twitch/Youtube but self-hosted. It has all the features you’d come to expect, a chat, support for chatbots, recordings, scheduled streams, stream discovery, etc.

Why I Didn’t Pick It

OwnCast is really great — for what it promises to be. Unfortunately, OwnCast uses HLS for client-side delivery, which is generally acceptable for live streamers as a few seconds of latency isn’t a concern. As for my use case, the poor latency and, most importantly, the desync that happens with HLS/DASH is unbearable when everyone is trying to react to—let’s say— a jumpscare simultaneously. All in all, still a great project. While I moved on from it relatively quickly, it deserved a shoutout as it could be perfect for some.

https://github.com/GRVYDEV/Project-Lightspeed

After hours of scouring Google, I found this project as a reply to a Reddit post asking for a self-hosted live streaming platform. The project advertises the use of FTL, which is ideal for a low-latency setup.

A self contained OBS -> FTL -> WebRTC live streaming server. Comprised of 3 parts once configured anyone can achieve sub-second OBS to the browser livestreaming

Overview

Project-Lightspeed comprises 3 parts, an ingest server, a WebRTC server, and a webserver based on React. This project was initially a little confusing to set up, as the guide assumes a reasonably decent knowledge in compilation and how to work the different programming languages. You can either install and run them separately or use Docker-Compose to build and tie them together. Ultimately I went with the Docker route, which unfortunately was also my first time dabbling in Docker and Docker Compose.

The Experience

When I got it installed, the initial impression was that the latency was good, which is excellent news! However, there were quite some issues with this project. It was tough for me to customize my setup. I didn’t know how to customize the landing page nor get HTTPS/WSS working. In fairness to the project, I was still pretty much a newbie when it came to dealing with docker, golang, npm, etc. So it took a fair bit for me to tinker around. Also, FTL turned out to be a pain in the butt as the stream occasionally stutters and freezes, which was very unpleasant. I’m not too sure what was causing it but from what I’ve read online this tends to be a problem with FTL. I personally haven’t looked into it much either so yeah…

Either way, the main reason I moved on from this project was due to the incompatibility with Apple’s Safari. This meant that iDevices couldn’t watch the stream and macOS users had to use Chrome which is a battery hog. I couldn’t quite figure out why, and it seemed like it wouldn’t be an easy fix either.

Conclusion

Regardless, massive props to the developer of this project. For a one-person team(and the contributors), this is still VERY impressive and very promising. The project hasn’t been updated for quite some time, but the developer is said to be planning on a rework of the project.

https://www.ovenmediaengine.com/ome

Next, I found OvenMediaEngine. Now this thing actually looks pretty legit! It honestly seems to be the best project I’ve discovered far and is the one that I currently have deployed for my personal use.

OvenMediaEngine (OME) is an Open-Source Streaming Server with Sub-Second Latency. It receives a video/audio source from encoders and cameras such as OvenStreamEncoder, OBS, or XSplit to WebRTC, RTMP, SRT, MPEG-2 TS, RTSP. Then, OME transmits it using WebRTC, Low Latency DASH (LL-DASH), MPEG-DASH, HLS.

Overview

It is incredibly feature-rich, low-latency, and overall extremely reliable. The overview of the setup is OBS -> OME -> OP

OvenMediaEngine(OME) is the first half of the streaming setup. Its role is to receive a stream from the source computer through RTMP or SRT and then transcode/output the HLS/DASH/WebRTC streams. It handles all the WebRTC signaling, the stream negotiation, etc.

The other half would be OvenPlayer, their recommended HTML player that you can just plop into any webpage. You can treat it like any other HTML player, which also provides you the flexibility to customize the page to your heart’s content. As for me, I made a simple HTML static site to server the player and host it using Cloudflare’s free Workers, and for the javascript, I simply linked it back to their demo site(more details in the guide post). Essentially, I don’t need to dedicate any resources to host the site for player. How cool!

OME has a whole lot more features and is designed for prime time use with scaling solutions and P2P streaming. It is a far more sophisticated piece of software, and amazingly, it is completely free and open source. Massive shoutout to the team at AirenSoft and all its contributors!

My Final Setup

I have installed it as a Docker container on my Raspberry Pi as it allows consolidation of everything and just makes everything tidier in general. It also simplifies the installation as I didn’t have to worry about minor differences between distros.

I will have a guide that goes much more in-depth about my setup and all the technical goodness. Getting OvenMediaEngine To Work.

Wrapping Up.

This is just a quick overview of my experiences with the different projects, I’ll have more details regarding OME for things like best settings etc.

At the moment, I’ve been using OME for a few months now, and everything works great. The latency is excellent with WebRTC, quality is also pretty decent. I’m pretty satisfied with my current setup. Say bye-bye to crusty discord screen share and hello to smooth & crystal clear entertainment with friends. Whenever we wanna watch or share something, all we have to do is open a page and the stream just starts working. No plugins, no configuration, nada.

Obviously there are still far more solutions out there that I didn’t cover, but those are typically for commercial purposes and require costly licenses. For my use, OME is more than adequate, however, I’m also interested to see what other shenanigans I can do with this.