Sätta upp en streamingserver: en uppladdning för hur många tittare som helst

Den som streamar utan egen server skickar sin bild till varje tittare separat. Tio tittare betyder tio gånger samma data, hundra tittare hundra gånger. Uppladdningen hemma eller på kontoret är därmed full efter några få tittare, och bilden börjar hacka trots att datorn knappt har något att göra.

En streamingserver vänder på det: du sänder exakt en ström till servern, och servern försörjer alla tittare med den. Din egen uppkoppling bär därmed alltid bara en enda uppladdning, helt oavsett om tio eller tiotusen personer tittar. Den här artikeln visar varför det fungerar så bra, hur du sätter upp en sådan server, vilken fördröjning varje protokoll kostar och hur mycket trafik det faktiskt blir.

Problemet: din uppladdning är flaskhalsen

Video är en oavbruten ström. En ström i 1080p med 60 bilder per sekund behöver 4,5 till 8 Mbit/s beroende på innehåll, 720p ligger på 3 till 5 Mbit/s. Den här bitraten flyter per tittare, hela tiden, utan pauser.

En genomsnittlig hemanslutning i Tyskland klarar mellan 10 och 50 Mbit/s i uppladdning, även många fiberanslutningar ligger på 50 till 100 Mbit/s uppåt. Räkningen tar därför snabbt slut:

Dessutom finns ett andra problem som ofta förbises: din anslutning delar den här ledningen med allt annat i hushållet eller på kontoret. Så snart någon laddar upp en stor fil eller en säkerhetskopiering startar bryter strömmen samman. En server i datacentret har inte det problemet, där står anslutningen uteslutande till ditt förfogande.

Principen: en gång upp, många gånger ner

Uppbyggnaden består av tre delar:

• Sändaren, alltså OBS, ffmpeg eller en hårdvarubox, skickar en ström till servern. Det kallas ingest.
• Servern tar emot den här enda strömmen, lägger om den till önskat uppspelningsformat och håller den redo.
• Tittarna hämtar strömmen från servern. Det kallas egress och är den del som växer med antalet tittare.

Avgörande är asymmetrin: vägen från dig till servern går man en gång, vägen från servern till tittarna tusenfalt. Därför behöver din anslutning bara så mycket uppladdning som en enda ström, medan servern behöver en anslutning som håller jämna steg med publiken.

Hur mycket trafik det faktiskt blir

Bandbredden är bara halva räkningen. Mer intressant är volymen, för det är den många leverantörer fakturerar efter. Formeln är enkel:

Volym i GB = bitrate i Mbit/s × sekunder × tittare ÷ 8000

Några realistiska exempel:

Siffrorna i den sista kolumnen är skälet till att streaming och volymbaserad fakturering passar dåligt tillsammans. En enda välbesökt sändning kan göra slut på en hel månads inkluderade volym, och varje ytterligare terabyte debiteras sedan separat. Med ett paket med obegränsad trafik försvinner den räkningen helt: månadspriset är fast, oavsett om 200 GB eller 50 TB går genom ledningen.

Vilken programvara passar dig

Till att börja med är nginx med RTMP-modulen det mest närliggande valet: den finns överallt, är väl dokumenterad, och du kan senare använda samma server utan ombyggnad som webbserver för tittarsidan.

Sätta upp en streamingserver med nginx och RTMP

Installera

På Debian och Ubuntu levererar paketet libnginx-mod-rtmp modulen, du behöver inte kompilera något själv:

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

På AlmaLinux och Rocky Linux kommer modulen från EPEL-förrådet:

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

Konfigurera

RTMP-delen står i nginx.conf utanför http-blocket, det är det vanligaste nybörjarfelet. En slimmad, fungerande version ser ut så här:

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # HLS för vanliga tittare
            hls on;
            hls_path /var/www/stream/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;

            # bara den egna adressen får sända
            allow publish 203.0.113.10;
            deny publish all;

            # alla får titta
            allow play all;
        }
    }
}

HLS-filerna levereras sedan av den vanliga webbservern. Det räcker med ett litet block i http-delen:

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 *;
    }
}

Skapa katalogen, kontrollera konfigurationen, starta om:

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

Öppna portarna

RTMP körs på port 1935, leveransen över 80 och 443. Med nftables eller ufw:

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

Observera den första raden: sändningsporten är bara öppen för din egen adress. En RTMP-port som står öppen mot hela världen hittas inom några få dagar, eftersom hela adressintervall söks igenom automatiskt, och då sänder någon annan över din ledning.

Sända med OBS

I OBS under Inställningar, Stream, ange tjänsten ”Anpassad”:

Under Utdata ställer du in bitraten. Som riktvärde: 1080p60 med 6000 kbit/s, 1080p30 med 4500 kbit/s, 720p30 med 3000 kbit/s. Sätt keyframe-avståndet till 2 sekunder, annars uppstår ojämna segment vid HLS och spelaren hackar vid omkopplingen.

Titta

Strömmen ligger därefter under https://stream.example.com/hls/kanal1.m3u8 och går att öppna med vilken HLS-kapabel spelare som helst, i webbläsaren till exempel med hls.js eller Video.js. För en snabb kontroll räcker VLC via ”Öppna nätverksström”.

Sända till flera plattformar samtidigt

Det är den andra stora fördelen med en egen server. I stället för att spränga din ledning med tre parallella uppladdningar sänder du en gång till servern, och den fördelar vidare. Till det lägger du till en rad per mål i application-blocket:

application live {
    live on;
    record off;

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

Din uppladdning stannar vid en enda ström. Mångfaldigandet sköter servern, och där är bandbredd precis det den finns till för.

Fördröjning: vilket protokoll till vad

Fördröjningen uppstår nästan helt vid uppspelningen, inte vid sändningen. Det är viktigt att förstå, eftersom många letar på fel ställe:

Ju lägre fördröjning, desto dyrare blir den enskilda tittaren. HLS är billigast, eftersom det består av enkla filer som varje webbserver och varje cache kan leverera. WebRTC håller däremot en egen anslutning öppen för varje tittare och kostar därmed betydligt mer beräkningskraft. Välj den låga fördröjningen bara där du verkligen behöver den.

Transkodning: när det lönar sig

Så länge servern bara skickar strömmen vidare behöver den nästan ingen beräkningskraft. En enda modern kärna betjänar på det sättet flera hundra tittare, flaskhalsen är enbart anslutningen.

Så snart du vill erbjuda flera kvalitetsnivåer, så att även tittare med svag uppkoppling kan se på, ändras det. Varje ytterligare nivå måste beräknas:

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

Räkna med två till fyra kärnor per nivå. Tre nivåer binder därmed redan åtta till tolv kärnor permanent. Fundera därför noga på om du behöver dem: för en publik som till största delen sitter vid datorn eller i wifi räcker ofta en enda väl vald nivå.

Säkra upp: vem får sända

En streamingserver är synlig utifrån och den blir hittad. Tre åtgärder räcker i vardagen:

• Brandvägg på sändningsporten. Bara din egen adress får nå 1935. Byter din adress använder du i stället en VPN-anslutning till servern.
• Kontrollera streamnyckeln. Med on_publish anropar nginx vid varje sändningsförsök ett litet skript, som kontrollerar nyckeln mot en lista och avvisar den om den inte stämmer.
• Grundskydd mot överbelastning. En streamingserver är ett lockande mål, eftersom ett avbrott syns omedelbart. Hos KernelHost ligger ett floodskydd med 3,2 Tbps kapacitet på varje server, utan att du behöver ställa in något. Mer om det på sidan om DDoS-skyddet.

Platsval och flera servrar

Servern hör inte hemma nära dig, utan nära dina tittare. Din egen anslutning till servern byggs upp en gång och löper sedan stabilt, även över en halv kontinent. Anslutningen till tittarna avgör däremot laddningstid och avhoppsfrekvens.

Sitter din publik övervägande i Europa är en plats i Tyskland rätt. Fördelar den sig över flera kontinenter lönar det sig med en andra server och fördelning via DNS, så att varje tittare landar hos den närmaste. KernelHost erbjuder platser i Tyskland, på USA:s västkust, på USA:s östkust samt i Singapore och Sydkorea, en översikt hittar du under Serverplatser.

Om du distribuerar filer i stället för livebilder, alltså uppdateringar, bilder eller videoarkiv, är inte en streamingserver rätt verktyg, utan en cache framför. Hur det fungerar står i artikeln Bygg en egen CDN-server.

Vilken server passar

För en streamingserver gäller en annan ordning än för en webbserver:

1. Anslutning och trafik. Det är flaskhalsen, och det är det alltid. En riktig gigabitanslutning utan strypning bär omkring 160 tittare vid 6 Mbit/s.
2. Obegränsad trafik. Volymbaserade paket är knappt möjliga att kalkylera för streaming, eftersom en enda lyckad kväll gör slut på månadsvolymen.
3. Processor. Andrahandsfråga, så länge du inte transkodar. Vid transkodning blir den den andra flaskhalsen.
4. RAM och disk. Minst kritiskt. Först när du behåller inspelningar blir diskutrymmet ett ämne.

Precis för det här fallet är våra rootservrar med obegränsad trafik gjorda: riktig anslutning med 2 × 1 Gbit/s per server, obegränsad volym utan strypning, ett fast månadspris oberoende av överförd mängd, och 3,2 Tbps floodskydd från fabrik. Servern är driftklar på under 30 sekunder, med full root-åtkomst, IPv4 och ett /64-IPv6-nät. Faktureringen sker på PrePaid-basis och går att säga upp varje månad, så du kan börja med ett litet paket och växa när din publik växer.