moanos/hyteck-blog
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Extend owncast tut

Browse Source
This commit is contained in:
moanos [he/him] 2021-05-23 09:00:27 +02:00
parent 7b9f851d23
commit 609604a187
1 changed files with 11 additions and 40 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
content/post/owncast.md
View File

@ -3,7 +3,7 @@ title: "Owncast & Streaming a talk"
date: 2021-05-20T16:08:55+02:00 date: 2021-05-20T16:08:55+02:00
draft: false draft: false
image: "uploads/owncast_logo.svg" image: "uploads/owncast_logo.svg"
tags: [FOSS] tags: [FOSS, Owncast, SmallWeb, Streaming, Self-Hosting, NGINX]
categories: [Projects, English] categories: [Projects, English]
--- ---
@ -159,7 +159,7 @@ There is a neat [project for live streaming directly from a BBB room](https://gi
# Performance # Performance
It can be hard to estimate the needed server capacities for a livestream. I want to share my experiences. 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. 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.
@ -169,51 +169,22 @@ The network load scales linear with the participants that are watching. You can
Downlink capacity = Num. participants x Outbound Video Stream Rate 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](/uploads/monitoring_vortrag.png "Grafana Screenshot") ![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](/uploads/monitoring_vortrag.png "Grafana Screenshot")
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. 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](/uploads/vortrag_eg.png "Screenshot of the owncast admin panel") ![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](/uploads/vortrag_eg.png "Screenshot of the owncast admin panel")
# Final notes If your bottleneck is the bandwidth you can try to add a second low streamrate, maybe ome clients will take that one.
=======
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](https://github.com/aau-zid/BigBlueButton-liveStreaming), 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. I want to share my experiences.
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
```
![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](/uploads/monitoring_vortrag.png "Grafana Screenshot")
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](/uploads/vortrag_eg.png "Screenshot of the owncast admin panel")
# Final notes # Final notes