Streamovací server: jeden upload pro libovolný počet diváků

Kdo streamuje bez vlastního serveru, posílá svůj obraz každému divákovi zvlášť. Deset diváků znamená desetkrát tatáž data, sto diváků stokrát. Upload doma nebo v kanceláři je tím po několika divácích zaplněný a obraz se začne zasekávat, přestože se počítač nudí.

Streamovací server to obrací: pošlete na server přesně jeden stream a server z něj zásobí všechny diváky. Vaše vlastní linka tak nese vždy jen jediný upload, úplně bez ohledu na to, zda se dívá deset nebo deset tisíc lidí. Tento článek ukazuje, proč to funguje tak dobře, jak takový server postavíte, jaké zpoždění stojí který protokol a kolik trafficu se při tom skutečně nasčítá.

Problém: vaše upload linka je úzké hrdlo

Video je trvalý tok. Stream v 1080p při 60 obrazech za sekundu potřebuje podle obsahu 4,5 až 8 Mbit/s, 720p leží na 3 až 5 Mbit/s. Tato bitrate teče na každého diváka, celou dobu, bez pauzy.

Průměrná domácí přípojka v Německu zvládne v uploadu mezi 10 a 50 Mbit/s, i mnoho optických přípojek leží v uploadu na 50 až 100 Mbit/s. Výpočet je proto rychle u konce:

K tomu přichází druhý problém, který se často přehlíží: vaše přípojka dělí tuto linku se vším ostatním v domácnosti nebo v kanceláři. Jakmile někdo nahraje velký soubor nebo se rozběhne záloha, stream se propadne. Server v datovém centru tento problém nemá, tam je konektivita k dispozici výhradně vám.

Princip: jednou nahoru, mnohokrát dolů

Stavba se skládá ze tří částí:

• Vysílač, tedy OBS, ffmpeg nebo hardwarová krabička, posílá jeden stream na server. Tomu se říká ingest.
• Server tento jeden stream přijme, převede ho do požadovaného výstupního formátu a drží ho připravený.
• Diváci si stream vyzvednou ze serveru. Tomu se říká egress a je to ta část, která roste s počtem diváků.

Rozhodující je asymetrie: cesta od vás k serveru se jde jednou, cesta od serveru k divákům tisíckrát. Proto vaše přípojka potřebuje jen tolik uploadu jako jediný stream, zatímco server potřebuje konektivitu, která drží krok s publikem.

Kolik trafficu se skutečně nasčítá

Pásmo je jen polovina výpočtu. Zajímavější je objem, protože podle něj mnoho poskytovatelů účtuje. Vzorec je jednoduchý:

objem v GB = bitrate v Mbit/s × sekundy × diváci ÷ 8000

Několik realistických příkladů:

Čísla v posledním sloupci jsou důvod, proč k sobě streamování a účtování podle objemu špatně pasují. Jediný dobře navštívený přenos může spotřebovat objem zahrnutý v ceně za celý měsíc a každý další terabyte se pak účtuje zvlášť. U tarifu s neomezeným trafficem tento výpočet zcela odpadá: měsíční cena je pevná, ať linkou projde 200 GB nebo 50 TB.

Jaký software se k vám hodí

Pro začátek je nginx s modulem RTMP nejnasnadnější volba: je všude dostupný, dobře zdokumentovaný a stejný server můžete později bez přestavby použít jako webový server pro divácké stránky.

Postavit streamovací server s nginx a RTMP

Instalace

Na Debianu a Ubuntu přináší modul balíček libnginx-mod-rtmp, nemusíte nic kompilovat sami:

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

Na AlmaLinuxu a Rocky Linuxu přichází modul z repozitáře EPEL:

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

Konfigurace

Část RTMP stojí v nginx.conf mimo blok http, to je nejčastější chyba začátečníků. Úsporná, funkční verze vypadá takto:

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # HLS pro běžné diváky
            hls on;
            hls_path /var/www/stream/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;

            # vysílat se smí jen z vlastní adresy
            allow publish 203.0.113.10;
            deny publish all;

            # dívat se smí každý
            allow play all;
        }
    }
}

Soubory HLS pak vydává běžný webový server. Na to stačí malý blok v části http:

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

Vytvořit adresář, zkontrolovat konfiguraci, znovu spustit:

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

Uvolnit porty

RTMP běží na portu 1935, výdej přes 80 a 443. S nftables nebo ufw:

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

Všimněte si prvního řádku: vysílací port je otevřený jen pro vaši vlastní adresu. Celosvětově otevřený port RTMP se najde během několika dní, protože se automaticky prohledávají celé rozsahy adres, a pak přes vaši linku vysílá někdo jiný.

Vysílání z OBS

V OBS v nastavení, Vysílání, zadejte službu „Vlastní“:

V části Výstup nastavíte bitrate. Jako orientační hodnoty: 1080p60 s 6000 kbit/s, 1080p30 s 4500 kbit/s, 720p30 s 3000 kbit/s. Vzdálenost klíčových snímků nastavte na 2 sekundy, jinak u HLS vznikají nepravidelné segmenty a přehrávač se při přepínání zasekává.

Sledování

Stream pak leží na https://stream.example.com/hls/kanal1.m3u8 a lze ho otevřít v každém přehrávači, který zvládá HLS, v prohlížeči například pomocí hls.js nebo Video.js. Na rychlou kontrolu stačí VLC přes „Otevřít síťový stream“.

Vysílat současně na více platforem

To je druhá velká výhoda vlastního serveru. Místo abyste třemi paralelními uploady roztrhli svou linku, odešlete stream jednou na server a ten ho rozdá dál. Doplníte k tomu v bloku application jeden řádek na každý cíl:

application live {
    live on;
    record off;

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

Váš upload při tom zůstává u jediného streamu. Rozmnožení převezme server a tam je pásmo přesně tím, pro co tu je.

Zpoždění: který protokol na co

Zpoždění vzniká téměř celé při přehrávání, ne při vysílání. To je důležité pochopit, protože mnozí hledají na nesprávném místě:

Čím nižší zpoždění, tím dražší je jednotlivý divák. HLS je nejlevnější, protože se skládá z obyčejných souborů, které umí vydat každý webový server a každá cache. WebRTC naproti tomu drží pro každého diváka otevřené vlastní spojení, a stojí tak výrazně více výpočetního výkonu. Nízké zpoždění berte jen tam, kde ho skutečně potřebujete.

Transkódování: kdy se vyplatí

Dokud server stream jen předává dál, nepotřebuje téměř žádný výpočetní výkon. Jediné moderní jádro takto obslouží několik set diváků, úzkým hrdlem je jedině konektivita.

Jakmile chcete nabízet více kvalitativních stupňů, aby se mohli dívat i diváci se slabým připojením, mění se to. Každý další stupeň se musí přepočítat:

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

Počítejte se dvěma až čtyřmi jádry na každý stupeň. Tři stupně tak trvale zaberou osm až dvanáct jader. Dobře si proto promyslete, zda je potřebujete: pro publikum, které sedí převážně u počítače nebo na Wi-Fi, často stačí jediný dobře zvolený stupeň.

Zabezpečení: kdo smí vysílat

Streamovací server je zvenčí vidět a najde se. Pro každodenní provoz stačí tři opatření:

• Firewall na vysílací port. Na 1935 smí jen vaše vlastní adresa. Pokud se vaše adresa mění, použijte místo toho přístup na server přes VPN.
• Kontrola stream klíče. Pomocí on_publish vyvolá nginx při každém pokusu o vysílání malý skript, který klíč porovná se seznamem a při neshodě ho odmítne.
• Základní ochrana proti přetížení. Streamovací server je vděčný cíl, protože výpadek je okamžitě vidět. U KernelHostu leží na každém serveru ochrana proti floodu s kapacitou 3,2 Tbps, aniž byste museli cokoli nastavovat. Více k tomu na stránce o ochraně proti DDoS.

Volba lokality a více serverů

Server nepatří blízko k vám, ale blízko k vašim divákům. Vaše vlastní spojení k serveru se postaví jednou a pak běží stabilně, i přes půl kontinentu. Spojení k divákům naproti tomu rozhoduje o době načítání a o tom, kolik lidí přenos opustí.

Sedí-li vaše publikum převážně v Evropě, je lokalita v Německu správná volba. Pokud se rozkládá přes více kontinentů, vyplatí se druhý server a rozdělení přes DNS, aby každý divák skončil u toho nejbližšího. KernelHost k tomu nabízí lokality v Německu, na západním pobřeží USA, na východním pobřeží USA a také v Singapuru a Jižní Koreji, přehled najdete na stránce lokality serverů.

Pokud rozdáváte soubory místo živého obrazu, tedy aktualizace, obrázky nebo videoarchivy, není správným nástrojem streamovací server, ale cache před ním. Jak to funguje, stojí v článku Postavit vlastní CDN server.

Který server se hodí

U streamovacího serveru platí jiné pořadí než u webového serveru:

1. Konektivita a traffic. To je úzké hrdlo, a to vždy. Skutečná gigabitová konektivita bez omezování rychlosti unese přibližně 160 diváků při 6 Mbit/s.
2. Neomezený traffic. Tarify podle objemu jsou u streamování téměř nespočitatelné, protože jediný úspěšný večer spotřebuje měsíční objem.
3. CPU. Druhořadé, dokud netranskódujete. Při transkódování se stane druhým úzkým hrdlem.
4. RAM a disk. Nejméně kritické. Teprve když si necháváte nahrávky, stává se místo na disku tématem.

Přesně na tento případ jsou ušité naše root servery s neomezeným trafficem: skutečná konektivita 2 × 1 Gbit/s na server, neomezený objem bez omezování rychlosti, pevná měsíční cena nezávislá na přeneseném množství a ochrana proti floodu 3,2 Tbps z výroby. Server je připravený za méně než 30 sekund, s plným root přístupem, IPv4 a sítí /64 IPv6. Účtuje se na předplacené bázi s možností zrušit kdykoli na konci měsíce, můžete tedy začít s malým tarifem a růst, až bude růst vaše publikum.