Owncast & Streaming a talk

I recently installed an Owncast server and wanted to share my experience. Here it is:

What is owncast?

Owncast is a streaming server that you can selfhost, a Twicht in a box as the developers call it. You host owncast on your server (a small VM with good downlink is enough) and can stream your own own content like you would do on Twicht, YouTube etc…

It has a chat, a admin panel for customization and thats it! You don’t need more to e.g. stream while you are playing minecraft or want to share a talk.

Getting started

Get the latest release on GitHub by using

$ mkdir owncast
$ cd owncast
$ wget https://github.com/owncast/owncast/releases/download/v0.0.7/owncast-0.0.7-linux-64bit.zip
$ unzip owncast-0.0.7-linux-64bit.zip
$ rm owncast-0.0.7-linux-64bit.zip

And move the webroot to your document root and make sure the permissions fit

$ cd ..
$ mv owncast /var/www/owncast
$ cd /var/www/
$ chown -R www-data:www-data owncast

Now create a new NGINX site e.g. /etc/nginx/sites-enabled/owncast with the following content

map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
}

server {


    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/stream.hyteck.de/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/stream.hyteck.de/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    server_name stream.hyteck.de;


    # Set header
    add_header X-Clacks-Overhead "GNU Terry Pratchett";
    add_header Permissions-Policy interest-cohort=(); #Anti FLoC


    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_pass http://127.0.0.1:8080;

    }

}

server {
        listen 80;
        listen [::]:80;
        server_name stream.hyteck.de;
        return 301 https://$server_name$request_uri;
}

Make sure to adjust the server name and SSL certificats (I will not go into detail on how to obtain them, but feel free to ask me!).

Start server

Now start owncast to test

$ cd /var/www/owncast
$ ./owncast/owncast

and visit https://yourdomain.org! If everything works you should see your site now. By visiting https://yourdomain.org/admin you can configure your server. The default credentials are admin and your stream key which is abc123. Change this immediately!

Before you configure, let’s make sure this runs whenever your server starts. Goback in the terminal and cancel with Ctrl+C.

Run as system service

You want to install owncast as a system service. Therfore create /etc/systemd/system/owncast.service with the following content:

[Unit]
Description=Owncast
After=network.target

[Service]
Type=simple
Restart=always
RestartSec=1
WorkingDirectory=/var/www/owncast
ExecStart=/var/www/owncast/owncast

[Install]
WantedBy=multi-user.target

Update the daemon with systemctl daemon-reload enable systemctl enable owncast and start with systemctl start owncast. Make sure everything is correct with systemctl status owncast.

Configuration

You can now change back to yourdoiman.org/admin and configure, title, logo and more.

Directory

If you start a stream and have directory enabled, Owncast will publish your activity, e.g. in the owncast RocketChat, on Twitter (by mentioning you if you gave Owncast your Twitter Handle) and in the Fediverse. Turn this of for testing!

Streaming

You can now use OBS or similar software to start streaming. Got to settings and configure your server.

Configuration in the OBS streaming tab. The service is set to Custom.. and the server to rtmp://stream.hyteck.de/live. The stream key is hidden

Concept for talks

To livestream we have a few important things to take care of:

  • The speaker
  • The presentation
  • The streaming software
  • The streaming server
  • The chat

I suggest the following setup. Moderation and Speaker are in a BigBlueButton conference. The meet 15 minutes in advance, enough time to upload a presentation. Also in this room is a user called stream. This user does only listen and has OBS configured to record audio and the (fullscreen) window of the BBB room.

Before the talk starts, it is a good opportunity to play some videos via the stream, or simply put on a picture, saing the talk will start soon.

When the speaker an moderation are ready they tell the streamer and the scene is switched to the BBB room. The recording is started (if needed).

A weakness of the setup is the streaner. If they loose their network connection, the stream stops.

There is a neat project for live streaming directly from a BBB room, but it is quite complicated to set up and a crash of the BBB server would make stop the stream. Also the start of the stream is not as beautiful.

Performance

It can be hard to estimate the needed server capacities for a livestream that is why I want to share my experiences. All of this was done on a Strato Linux V40 with 16 GB of RAM, 8 vCPUs and 500 MBit/s.

On the following screenshots you see the configuration and the monitoring data of a talk with 40 participants. We pplayed high-quality videos from 17:43 to 18:05. At 18:05 we changed to the presentation. You see the decrease in CPU load, as the compression of the videos was easier with a steady picture. At 19:05 we invited the participents to join us in the BBB room, some left the stream.

The network load scales linear with the participants that are watching. You can simply calculate the needed downlink capacity with

Downlink capacity = Num. participants x Outbound Video Stream Rate

Here this was

40 participants x 1200 kbps = 48 Mbps

which matches the observed network traffic quite well.

Chart of the CPU load and the network traffic basic. The CPU load was jumpy around 25% from 17:45 to 18:05, after that it was steady around 17.5%. The Network Traffic went up until 18:10 and stayed at 50 Mbps until 19:00

The CPU load is determined by the compression the server has to do. The more different stream formats the server has to put out, the higher the load becomes. On the given Screenshot you see that only one downlink format was advertised, so the inbound stream had to be compresse only once. Matching imbound and outbound stream formats help reducing the server load.

A screenshot of the Owncast admin panel. The outbound stream details are: 1200 kbps, 24 fps and the Input is H.264@2500kbps at 30 fps

If your bottleneck is the bandwidth you can try to add a second low streamrate, maybe ome clients will take that one.

Final notes

Owncast is a great project. Be aware that it is still not in version 1.0 so expect some limitations. This is e.g. the unability to block a user from chat. If you have any questions or comments, let me know

Student of Medical Informatics, Developer, He/Him