b1e1d0168a
Update the module path |
||
---|---|---|
config | ||
doc | ||
scripts | ||
static | ||
webroot | ||
.gitignore | ||
chunkStorage.go | ||
client.go | ||
config.go | ||
Dockerfile | ||
ffmpeg.go | ||
go.mod | ||
go.sum | ||
handler.go | ||
ipfsStorage.go | ||
main.go | ||
message.go | ||
playlistMonitor.go | ||
README.md | ||
rtmp.go | ||
s3Storage.go | ||
server.go | ||
stats.go | ||
status.go | ||
thumbnailGenerator.go | ||
utils.go |
Take control over your content and stream it yourself.
Explore the docs »
View Demo
·
Report Bug
Table of Contents
- About the Project
- Getting Started
- Use with your software
- Video storage and distribution options
- Advanced usage
- Building from source
- Roadmap
- License
- Contact
About The Project
This is a work in progress. The web UI is being worked on and functionality is still being tested and iterated on. Feel free to test and give feedback, but it's not ready for production.
In 2020 the world changed when everyone become stuck in their homes, looking for creative outlets to share their art, skills and themselves from inside their bedroom.
This created an explosion of live streaming on Facebook Live, YouTube Live, Instagram, and Twitch. These services provided everything they needed, an easy way to live stream to the world, and a chat for users to be a part of their community.
But in a world where many were previously finding ways to rely on the big internet service companies less, the 2020 COVID-19 pandemic made everyone run right back to them.
And as soon as people started streaming their DJ sets, movie watching parties, and themselves just sitting around listening to music the big companies came to mute their streams, remove their recordings or ban these users all together.
That's when I wanted a better option for people. Something you could run yourself and get all the functionality of these services, where you could live stream to an audience and and allow them to take part in the chat, just like they've been used to on all the other services. But instead of handing control over to somebody else, you run it. You won't get shut down, and you own it all, just like it should be.
I figured you can install Wordpress and self-host your blog, or install Megento and self-host your e-commerce site. You can install Icecast and have your own internet radio station. Spin up an instance of Mastodon and you have your own social media site that you control. You can even install Nextcloud and have your own personal productivity service replacing Dropbox and Google Docs. There's an open-source alternative to all the big services that you can run for almost everything, but I couldn't think of what the live video streaming equivalent was. There should be a independent, standalone Twitch in a Box.
Keep in mind that while streaming to the big social companies is always free, you pay for it with your identity and your data, as well as the identity and data of every person that tunes in. When you self-host anything you'll have to pay with your money instead. But running a self-hosted live stream server can be done for as cheap as $5/mo, and that's a much better deal than selling your soul to Facebook, Google or Amazon.
Getting Started
The goal is to have a single service that you can run and it works out of the box, but there are some things you need to have, and some choices you might want to make.
Prerequisites
-
A computer that's on the public internet to run it on. While crunching through video and serving it to viewers can be intensive from the computing side, you can get away with pretty meager resources. If you don't already have a server to run it on you can get a Linode instance for $5/mo that runs it fine. If you worry that you'll be maxing out the bandwidth or transfer limits allotted to you, then utilize S3 Storage very cheaply (or even free for a certain amount) to serve the files instead.
-
ffmpeg is required to function. Install it first.
-
These instructions are assuming you're using OBS on your personal computer to stream from. It's not required, but it's a great free piece of software.
Installation
- TODO: Once it's installable add directions here.
- Copy config/config-example.yaml to config/config.yaml.
- Edit the config file and point it to
ffmpeg
- Set a custom streaming key by editing
streamingKey
in your config.
Usage
- Run
./owncloud
from the directory you unzipped it. - Open your web browser and visit http://yourserver:8080/. If you changed the port in the config file, then change the URL accordingly. If you are testing this on your own personal computer then you can visit http://localhost:8080.
Docker
If you want a simpler way to run an instance of owncast you can run it in a container with the supplied Dockerfile.
- Copy
config/config-example.yaml
toconfig/config.yaml
- Edit
config/config.yaml
and change the path of ffmpeg to/usr/bin/ffmpeg
- Make any other config changes.
- Run
docker build -t owncast .
and wait. It may take a few minutes to build. - Run
docker run -p 8080:8080 -p 1935:1935 -it owncast
- If you ever make any future config file changes you must rerun the
docker build
step otherwise you can just run thedocker run
step to run the service going forward.
Use with your desktop software
Usage with OBS
- Install OBS or Streamlabs OBS and get it working with your local setup.
- Open OBS Settings and go to "Stream".
- Select "Custom..." as the service.
- Enter the URL of the server running your streaming service in the format of rtmp://myserver.net/live.
- Enter your "Stream Key" that matches the key you put in your
config.yaml
file. - Start the server.
- Press "Start Streaming" (OBS) or "Go Live" (Streamlabs) on OBS.
Usage with Restream
Read the detailed documentation for working with Restream
Video storage options
Three ways of storing and distributing the video are supported.
- Locally via the built-in web server.
- S3-compatible storage.
- Experimental IPFS support.
Local file distribution
This is the simplest and works out of the box. In this scenario video will be served to the public from the computer that is running the server. If you have a fast internet connection, enough bandwidth alotted to you, and a small audience this may be fine for many people.
S3-Compatible Storage
Enable S3 support in config.yaml
and add your access credentials. Files will be distributed from a S3 bucket that you have created for this purpose. This is a good option for almost any case since S3 is cheap and you don't have to worry about your own bandwidth.
Please read the more detailed documentation about configuration of S3-Compatible Services.
IPFS
From the IPFS website:
Peer-to-peer IPFS saves big on bandwidth — up to 60% for video — making it possible to efficiently distribute high volumes of data without duplication.
Enable experimental IPFS support and your video will be distributed through the IPFS network. In this scenario viewers will stream the video from IPFS nodes instead of the server running the service. This is free but can be very slow. It can also be just fine, you'll have to experiment for yourself. It can sometimes take too long for the network to get the video to the user, resulting in delays and heavy buffering. Try it if you like and make any suggestions on how to make it better so everyone can have free global video distribution without paying for a CDN or a 3rd party storage service.
By editing the config file you can change what IPFS gateway server is used, and you can experiment with trying different ones.
Advanced Usage
Here's a list of some things you can do to increase performance and make things nicer for yourself.
-
Get a faster server with more cores so you can enable more bitrates at once.
-
Put a CDN in front of your server if you serve your files locally. You can even get a free one like Cloudflare. Then as more people view your stream people will no longer be downloading the stream directly from your server, but from the CDN instead, and it'll be faster. This is also a good way to enable SSL for your site.
-
If you use S3 for storage, have it expire files from your bucket after N days because old files sitting on your S3 bucket aren't useful to anybody.
-
Edit the
webroot/index.html
file and make it look however you want. -
Add a
<video>
tag into your existing site and point it at your streaming server's/hls/stream.m3u8
file and not use the built in web UI at all. -
Run Nginx as a proxy somewhere to support SSL or caching.
Building from Source
- Install the Go toolchain.
- Clone the repo.
git clone https://github.com/gabek/owncast
- Follow the above Getting Started instructions, making sure ffmpeg exists and your config file is set.
go run *.go
on the first run will download the required packages needed for the application to build.- It will start running the same as in the above Usage instructions and you can point OBS to your localhost instance of it.
Roadmap
The following is a list of things, as long as there's some traction, I'd like to focus on.
-
Real web layout and chat UI is being worked on by gingervitis.
-
Document more non-Amazon owned, but still S3 compatible storage. There's so many services out there that are S3 compatible such as Backblaze, Google Storage, DreamHost DreamObjects, or you can even run your own. So it's good to have options.
-
Refactor chat so it's more controlled by the server and doesn't accept just anything from clients and relay it back to everyone.
-
Add more functionality to chat UI such as moderation (deleting messages), emojis/gif search, etc. You know, the stuff other services have and people are used to.
-
Collect viewer stats so you know how many people tuned into a stream. People seem to care about that kind of thing.
-
Add a simple setup wizard that will generate the config file for you on the first run by asking simple questions.
-
A web Admin UI that allows you to edit settings and view stats, moderate chat, etc.
-
Add built-in Let's Encrypt support so SSL is enabled out of the box.
License
Distributed under the MIT License. See LICENSE
for more information.
Contact
Gabe Kangas - @gabek@mastodon.social - email gabek@real-ity.com
Project Link: https://github.com/gabek/owncast