Streamserver opzetten: één upload voor onbeperkt veel kijkers

Wie zonder eigen server streamt, stuurt zijn beeld naar iedere kijker apart. Tien kijkers betekenen tien keer dezelfde gegevens, honderd kijkers honderd keer. De upload thuis of op kantoor zit daarmee na een handvol kijkers vol, en het beeld begint te haperen terwijl de computer zich verveelt.

Een streamserver draait dat om: u zendt precies één stream naar de server, en de server voorziet daarmee alle kijkers. Uw eigen verbinding draagt daardoor altijd maar één enkele upload, of er nu tien of tienduizend mensen meekijken. Dit artikel laat zien waarom dat zo goed werkt, hoe u zo'n server opzet, welk protocol welke vertraging kost en hoeveel dataverkeer er werkelijk bij elkaar komt.

Het probleem: uw upload is het knelpunt

Video is een doorlopende stroom. Een stream in 1080p met 60 beelden per seconde heeft afhankelijk van de inhoud 4,5 tot 8 Mbit/s nodig, 720p zit op 3 tot 5 Mbit/s. Die bitrate loopt per kijker, de hele tijd, zonder pauze.

Een gemiddelde thuisaansluiting in Duitsland haalt in de upload tussen 10 en 50 Mbit/s, en zelfs veel glasvezelaansluitingen blijven in de upload op 50 tot 100 Mbit/s steken. De rekening is daarom snel klaar:

Daar komt een tweede probleem bij dat vaak over het hoofd wordt gezien: uw aansluiting deelt die lijn met al het andere in huis of op kantoor. Zodra iemand een groot bestand uploadt of een back-up start, zakt de stream in. Een server in het datacenter heeft dat probleem niet, daar staat de verbinding uitsluitend tot uw beschikking.

Het principe: één keer omhoog, vele keren omlaag

De opbouw bestaat uit drie delen:

• De zender, dus OBS, ffmpeg of een hardwarekastje, stuurt één stream naar de server. Dat heet ingest.
• De server neemt die ene stream aan, zet hem om naar het gewenste uitleverformaat en houdt hem klaar.
• De kijkers halen de stream bij de server op. Dat heet egress en is het deel dat met het aantal kijkers meegroeit.

Beslissend is de asymmetrie: de weg van u naar de server wordt één keer afgelegd, de weg van de server naar de kijkers duizend keer. Daarom heeft uw aansluiting niet meer upload nodig dan één enkele stream vraagt, terwijl de server een verbinding nodig heeft die het publiek kan bijhouden.

Hoeveel dataverkeer er werkelijk bij elkaar komt

De bandbreedte is maar de helft van de rekening. Interessanter is het volume, want daarop rekenen veel aanbieders af. De formule is eenvoudig:

Volume in GB = bitrate in Mbit/s × seconden × kijkers ÷ 8000

Een paar realistische voorbeelden:

De getallen in de laatste kolom zijn de reden waarom streaming en afrekenen per volume slecht bij elkaar passen. Eén goed bezochte uitzending kan het inbegrepen volume van een hele maand opmaken, en elke verdere terabyte wordt dan apart in rekening gebracht. Bij een tarief met onbeperkt dataverkeer vervalt die rekening volledig: de maandprijs staat vast, of er nu 200 GB of 50 TB door de lijn gaat.

Welke software bij u past

Om te beginnen is nginx met de RTMP-module de meest logische keuze: het is overal beschikbaar, goed gedocumenteerd, en u kunt dezelfde server later zonder verbouwing als webserver voor de kijkerspagina gebruiken.

Een streamserver opzetten met nginx en RTMP

Installeren

Op Debian en Ubuntu levert het pakket libnginx-mod-rtmp de module mee, u hoeft zelf niets te compileren:

apt update
apt install -y nginx libnginx-mod-rtmp ffmpeg

Op AlmaLinux en Rocky Linux komt de module uit de EPEL-repository:

dnf install -y epel-release
dnf install -y nginx nginx-mod-rtmp ffmpeg

Configureren

Het RTMP-deel staat in nginx.conf buiten het http-blok, dat is de meestgemaakte beginnersfout. Een slanke, werkende versie ziet er zo uit:

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # HLS voor gewone kijkers
            hls on;
            hls_path /var/www/stream/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;

            # alleen vanaf het eigen adres mag worden gezonden
            allow publish 203.0.113.10;
            deny publish all;

            # kijken mag iedereen
            allow play all;
        }
    }
}

De HLS-bestanden levert daarna de gewone webserver uit. Daarvoor is een klein blok in het http-deel genoeg:

server {
    listen 80;
    server_name stream.example.com;

    location /hls {
        types {
            application/vnd.apple.mpegurl m3u8;
            video/mp2t ts;
        }
        root /var/www/stream;
        add_header Cache-Control no-cache;
        add_header Access-Control-Allow-Origin *;
    }
}

Map aanmaken, configuratie controleren, opnieuw starten:

mkdir -p /var/www/stream/hls
chown -R www-data:www-data /var/www/stream
nginx -t && systemctl reload nginx

Poorten vrijgeven

RTMP loopt op poort 1935, de uitlevering via 80 en 443. Met nftables of ufw:

ufw allow from 203.0.113.10 to any port 1935 proto tcp
ufw allow 80/tcp
ufw allow 443/tcp

Let op de eerste regel: de zendpoort staat alleen voor uw eigen adres open. Een wereldwijd open RTMP-poort wordt binnen een paar dagen gevonden, omdat hele adresreeksen automatisch worden afgezocht, en dan zendt iemand anders over uw lijn.

Zenden met OBS

In OBS onder Instellingen, Stream, bij Service "Aangepast" invullen:

Onder Uitvoer stelt u de bitrate in. Als richtwaarde: 1080p60 met 6000 kbit/s, 1080p30 met 4500 kbit/s, 720p30 met 3000 kbit/s. Zet de keyframe-afstand op 2 seconden, anders ontstaan bij HLS ongelijke segmenten en hapert de speler bij het omschakelen.

Kijken

De stream staat daarna op https://stream.example.com/hls/kanal1.m3u8 en is met elke speler te openen die HLS ondersteunt, in de browser bijvoorbeeld met hls.js of Video.js. Voor een snelle controle is VLC via "Netwerkstream openen" genoeg.

Tegelijk naar meerdere platforms zenden

Dat is het tweede grote voordeel van een eigen server. In plaats van uw lijn met drie gelijktijdige uploads op te blazen, zendt u één keer naar de server, en die verdeelt verder. Daarvoor vult u in het application-blok per doel één regel aan:

application live {
    live on;
    record off;

    push rtmp://live.plattform-a.example/app/STREAM_KEY;
    push rtmp://live.plattform-b.example/app/STREAM_KEY;
}

Uw upload blijft daarbij bij één enkele stream. Het vermenigvuldigen doet de server, en bandbreedte is precies waarvoor hij er staat.

Vertraging: welk protocol waarvoor

De vertraging ontstaat bijna volledig bij het uitleveren, niet bij het zenden. Dat is belangrijk om te begrijpen, want veel mensen zoeken op de verkeerde plek:

Hoe lager de vertraging, hoe duurder de afzonderlijke kijker wordt. HLS is het goedkoopst, omdat het uit gewone bestanden bestaat die elke webserver en elke cache kan uitleveren. WebRTC houdt daarentegen voor iedere kijker een eigen verbinding open en kost daarmee duidelijk meer rekenkracht. Kies de lage vertraging alleen daar waar u die echt nodig hebt.

Transcoderen: wanneer het de moeite waard is

Zolang de server de stream alleen maar doorgeeft, heeft hij bijna geen rekenkracht nodig. Eén moderne kern bedient op die manier enkele honderden kijkers, het knelpunt is alleen de verbinding.

Zodra u meerdere kwaliteitsniveaus wilt aanbieden, zodat ook kijkers met een zwakke verbinding mee kunnen kijken, verandert dat. Elk extra niveau moet worden omgerekend:

ffmpeg -i rtmp://127.0.0.1/live/kanal1 \
  -c:v libx264 -preset veryfast -b:v 3000k -s 1280x720 -c:a copy -f flv rtmp://127.0.0.1/live/kanal1_720 \
  -c:v libx264 -preset veryfast -b:v 1200k -s 854x480  -c:a copy -f flv rtmp://127.0.0.1/live/kanal1_480

Reken op twee tot vier kernen per niveau. Drie niveaus leggen daarmee al acht tot twaalf kernen permanent vast. Bedenk daarom goed of u ze nodig hebt: voor een publiek dat overwegend achter de computer of op wifi zit, is één goed gekozen niveau vaak genoeg.

Beveiligen: wie mag zenden

Een streamserver is van buiten zichtbaar en wordt gevonden. Drie maatregelen zijn genoeg voor de dagelijkse praktijk:

• Firewall op de zendpoort. Alleen uw eigen adres mag op 1935. Wisselt uw adres, gebruik dan een VPN-verbinding naar de server.
• Streamsleutel controleren. Met on_publish roept nginx bij elke zendpoging een klein script aan dat de sleutel tegen een lijst controleert en bij afwijking weigert.
• Basisbescherming tegen overbelasting. Een streamserver is een aantrekkelijk doelwit, omdat een storing direct zichtbaar is. Bij KernelHost heeft elke server een floodbescherming met 3,2 Tbps capaciteit, zonder dat u iets hoeft in te stellen. Meer daarover op de pagina over DDoS-bescherming.

Locatiekeuze en meerdere servers

De server hoort niet in uw buurt te staan, maar in de buurt van uw kijkers. Uw eigen verbinding naar de server wordt één keer opgebouwd en loopt daarna stabiel, zelfs over een half continent. De verbinding naar de kijkers bepaalt daarentegen de laadtijd en hoeveel kijkers afhaken.

Zit uw publiek overwegend in Europa, dan is een locatie in Duitsland de juiste keuze. Verdeelt het zich over meerdere continenten, dan is een tweede server met verdeling via DNS de moeite waard, zodat iedere kijker bij de dichtstbijzijnde locatie uitkomt. KernelHost biedt daarvoor locaties in Duitsland, aan de Amerikaanse westkust, aan de Amerikaanse oostkust en in Singapore en Zuid-Korea, een overzicht vindt u onder Serverlocaties.

Verdeelt u bestanden in plaats van livebeelden, dus updates, afbeeldingen of videoarchieven, dan is niet een streamserver het juiste gereedschap, maar een cache ervoor. Hoe dat werkt, staat in het artikel Een eigen CDN-server opzetten.

Welke server past

Voor een streamserver geldt een andere volgorde dan voor een webserver:

1. Verbinding en dataverkeer. Dat is het knelpunt, en wel altijd. Een echte gigabitverbinding zonder beperking draagt ongeveer 160 kijkers bij 6 Mbit/s.
2. Onbeperkt dataverkeer. Tarieven op volumebasis zijn voor streaming nauwelijks te begroten, omdat één geslaagde avond het maandvolume opmaakt.
3. CPU. Van tweede orde, zolang u niet transcodeert. Bij transcoderen wordt die het tweede knelpunt.
4. RAM en schijf. Het minst kritisch. Pas als u opnames bewaart, gaat schijfruimte meespelen.

Precies op dat geval zijn onze Unlimited-Traffic-rootservers toegesneden: een echte verbinding van 2 × 1 Gbit/s per server, onbeperkt volume zonder beperking, een vaste maandprijs onafhankelijk van de overgedragen hoeveelheid, en 3,2 Tbps floodbescherming standaard. De server staat in minder dan 30 seconden klaar, met volledige roottoegang, IPv4 en een /64-IPv6-netwerk. Er wordt op PrePaid-basis afgerekend en het abonnement is maandelijks opzegbaar, u kunt dus met een klein tarief beginnen en meegroeien als uw publiek groeit.