Konfiguracja serwera streamingowego: jedno wysyłanie dla dowolnej liczby widzów

Kto streamuje bez własnego serwera, wysyła swój obraz osobno do każdego widza. Dziesięciu widzów to dziesięć razy te same dane, stu widzów sto razy. Łącze wychodzące w domu albo w biurze jest przez to zapchane już po kilku widzach, a obraz zaczyna się zacinać, choć komputer się nudzi.

Serwer streamingowy odwraca ten układ: wysyłasz do serwera dokładnie jeden strumień, a serwer zasila nim wszystkich widzów. Twoje własne łącze przenosi dzięki temu zawsze tylko jedno jedyne wysyłanie, całkiem niezależnie od tego, czy patrzy dziesięć osób, czy dziesięć tysięcy. Ten artykuł pokazuje, dlaczego działa to tak dobrze, jak postawić taki serwer, które protokoły ile opóźnienia kosztują i ile transferu naprawdę się przy tym zbiera.

Problem: Twoje łącze wychodzące jest wąskim gardłem

Wideo to stały strumień. Strumień w 1080p przy 60 klatkach na sekundę potrzebuje, zależnie od treści, od 4,5 do 8 Mbit/s, 720p mieści się w 3 do 5 Mbit/s. Ten bitrate płynie na każdego widza osobno, cały czas, bez przerwy.

Przeciętne łącze domowe w Niemczech osiąga w górę od 10 do 50 Mbit/s, nawet wiele łączy światłowodowych kończy się w górę na 50 do 100 Mbit/s. Rachunek jest więc szybko zamknięty:

Dochodzi do tego drugi problem, który często się przeocza: Twoje łącze dzieli się z wszystkim innym w domu albo w biurze. Gdy tylko ktoś wysyła duży plik albo startuje kopia zapasowa, strumień się załamuje. Serwer w centrum danych tego problemu nie ma, tam łącze stoi wyłącznie do Twojej dyspozycji.

Zasada: raz w górę, wielokrotnie w dół

Konstrukcja składa się z trzech części:

• Nadajnik, czyli OBS, ffmpeg albo sprzętowy enkoder, wysyła jeden strumień do serwera. To się nazywa ingest.
• Serwer przyjmuje ten jeden strumień, przekłada go na wybrany format odtwarzania i trzyma w gotowości.
• Widzowie odbierają strumień z serwera. To się nazywa egress i jest tą częścią, która rośnie wraz z liczbą widzów.

Decydująca jest asymetria: drogę od Ciebie do serwera przechodzi się raz, drogę od serwera do widzów tysiąc razy. Dlatego Twoje łącze potrzebuje tylko tyle pasma w górę, ile zajmuje jeden strumień, natomiast serwer potrzebuje łącza, które nadąży za publicznością.

Ile transferu naprawdę się zbiera

Pasmo to tylko połowa rachunku. Ciekawszy jest wolumen, bo według niego wielu dostawców wystawia rachunki. Wzór jest prosty:

wolumen w GB = bitrate w Mbit/s × sekundy × widzowie ÷ 8000

Kilka realistycznych przykładów:

Liczby w ostatniej kolumnie są powodem, dla którego streaming i rozliczanie według wolumenu pasują do siebie słabo. Jedna jedyna dobrze odwiedzona transmisja potrafi zużyć wolumen wliczony w cały miesiąc, a każdy kolejny terabajt jest wtedy liczony osobno. W taryfie z nielimitowanym transferem ten rachunek znika całkowicie: cena miesięczna jest ustalona, niezależnie od tego, czy przez łącze przejdzie 200 GB, czy 50 TB.

Jakie oprogramowanie do Ciebie pasuje

Na początek nginx z modułem RTMP jest wyborem najbardziej oczywistym: jest dostępny wszędzie, dobrze udokumentowany, a ten sam serwer możesz później bez przebudowy wykorzystać jako serwer WWW dla strony dla widzów.

Stawianie serwera streamingowego na nginx i RTMP

Instalacja

W Debianie i Ubuntu moduł przynosi pakiet libnginx-mod-rtmp, nie musisz niczego kompilować samodzielnie:

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

W AlmaLinux i Rocky Linux moduł pochodzi z repozytorium EPEL:

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

Konfiguracja

Część RTMP stoi w pliku nginx.conf poza blokiem http, to najczęstszy błąd początkujących. Lekka, działająca wersja wygląda tak:

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # HLS dla zwykłych widzów
            hls on;
            hls_path /var/www/stream/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;

            # nadawać wolno tylko z własnego adresu
            allow publish 203.0.113.10;
            deny publish all;

            # patrzeć może każdy
            allow play all;
        }
    }
}

Pliki HLS wydaje potem zwykły serwer WWW. Wystarczy do tego mały blok w części 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 *;
    }
}

Utwórz katalog, sprawdź konfigurację, uruchom ponownie:

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

Otwieranie portów

RTMP działa na porcie 1935, wydawanie treści przez 80 i 443. Z nftables albo ufw:

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

Zwróć uwagę na pierwszą linię: port nadawania jest otwarty tylko dla Twojego własnego adresu. Otwarty na cały świat port RTMP zostanie znaleziony w ciągu kilku dni, bo całe zakresy adresów są automatycznie przeszukiwane, a wtedy ktoś inny nadaje przez Twoje łącze.

Nadawanie z OBS

W OBS, w Ustawieniach, w zakładce Transmisja, wpisz usługę „Własna”:

Bitrate ustawiasz w sekcji Wyjście. Jako wartości orientacyjne: 1080p60 przy 6000 kbit/s, 1080p30 przy 4500 kbit/s, 720p30 przy 3000 kbit/s. Ustaw odstęp między klatkami kluczowymi na 2 sekundy, inaczej przy HLS powstaną nieregularne segmenty i odtwarzacz będzie się zacinać przy przełączaniu.

Oglądanie

Strumień leży potem pod adresem https://stream.example.com/hls/kanal1.m3u8 i da się otworzyć dowolnym odtwarzaczem obsługującym HLS, w przeglądarce na przykład przez hls.js albo Video.js. Do szybkiego sprawdzenia wystarczy VLC przez „Otwórz strumień sieciowy”.

Nadawanie jednocześnie na kilka platform

To druga duża zaleta własnego serwera. Zamiast rozsadzać swoje łącze trzema równoległymi wysyłkami, wysyłasz raz do serwera, a ten rozdziela dalej. Dopisujesz do tego w bloku application jedną linię na każdy cel:

application live {
    live on;
    record off;

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

Twoje wysyłanie zostaje przy tym na jednym jedynym strumieniu. Zwielokrotnienie przejmuje serwer, a tam pasmo jest dokładnie tym, do czego on służy.

Opóźnienie: który protokół do czego

Opóźnienie powstaje niemal w całości po stronie odtwarzania, a nie nadawania. Warto to zrozumieć, bo wielu szuka w złym miejscu:

Im niższe opóźnienie, tym droższy staje się pojedynczy widz. HLS jest najtańszy, bo składa się ze zwykłych plików, które wyda każdy serwer WWW i każdy cache. WebRTC natomiast trzyma dla każdego widza otwarte osobne połączenie i kosztuje przez to wyraźnie więcej mocy obliczeniowej. Bierz niskie opóźnienie tylko tam, gdzie naprawdę go potrzebujesz.

Transkodowanie: kiedy się opłaca

Dopóki serwer tylko przekazuje strumień dalej, prawie nie potrzebuje mocy obliczeniowej. Jeden nowoczesny rdzeń obsługuje w ten sposób kilkuset widzów, wąskim gardłem jest wyłącznie łącze.

Gdy tylko zechcesz oferować kilka poziomów jakości, żeby mogli patrzeć także widzowie ze słabym połączeniem, sytuacja się zmienia. Każdy dodatkowy poziom musi zostać przeliczony:

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

Licz się z dwoma do czterech rdzeniami na poziom. Trzy poziomy wiążą więc już osiem do dwunastu rdzeni na stałe. Przemyśl więc dokładnie, czy ich potrzebujesz: dla publiczności, która siedzi głównie przy komputerze albo w Wi-Fi, często wystarcza jeden dobrze wybrany poziom.

Zabezpieczenie: kto może nadawać

Serwer streamingowy jest widoczny z zewnątrz i zostanie znaleziony. Do codzienności wystarczą trzy działania:

• Firewall na porcie nadawania. Na port 1935 wolno tylko Twojemu własnemu adresowi. Jeśli Twój adres się zmienia, użyj zamiast tego dostępu VPN do serwera.
• Sprawdzanie klucza strumienia. Przez on_publish nginx wywołuje przy każdej próbie nadawania mały skrypt, który sprawdza klucz na liście i przy niezgodności odrzuca połączenie.
• Podstawowa ochrona przed przeciążeniem. Serwer streamingowy jest atrakcyjnym celem, bo awaria jest natychmiast widoczna. W KernelHost na każdym serwerze leży ochrona przed zalewaniem o wydajności 3,2 Tbps, bez żadnej konfiguracji z Twojej strony. Więcej na stronie o ochronie DDoS.

Wybór lokalizacji i kilka serwerów

Serwer nie należy w Twoje sąsiedztwo, a w sąsiedztwo Twoich widzów. Twoje własne połączenie z serwerem zestawia się raz i potem działa stabilnie, nawet przez pół kontynentu. Natomiast połączenie do widzów decyduje o czasie ładowania i o tym, ilu zrezygnuje.

Jeśli Twoja publiczność siedzi głównie w Europie, lokalizacja w Niemczech jest właściwa. Gdy rozkłada się na kilka kontynentów, opłaca się drugi serwer i rozdzielanie przez DNS, tak żeby każdy widz trafiał na najbliższy. KernelHost oferuje do tego lokalizacje w Niemczech, na zachodnim i wschodnim wybrzeżu USA oraz w Singapurze i Korei Południowej, przegląd znajdziesz pod lokalizacje serwerów.

Jeśli rozdzielasz pliki, a nie obraz na żywo, czyli aktualizacje, zdjęcia albo archiwa wideo, właściwym narzędziem nie jest serwer streamingowy, a cache przed źródłem. Jak to działa, opisuje artykuł Budowa własnego serwera CDN.

Jaki serwer pasuje

Przy serwerze streamingowym liczy się inna kolejność niż przy serwerze WWW:

1. Łącze i transfer. To jest wąskie gardło, i to zawsze. Prawdziwe łącze gigabitowe bez dławienia przenosi około 160 widzów przy 6 Mbit/s.
2. Nielimitowany transfer. Taryfy rozliczane według wolumenu są przy streamingu praktycznie niemożliwe do policzenia, bo jeden jedyny udany wieczór zużywa wolumen miesiąca.
3. Procesor. Drugorzędny, dopóki nie transkodujesz. Przy transkodowaniu staje się drugim wąskim gardłem.
4. RAM i dysk. Najmniej krytyczne. Miejsce na dysku staje się tematem dopiero wtedy, gdy zachowujesz nagrania.

Dokładnie na ten przypadek skrojone są nasze serwery root z nielimitowanym transferem: prawdziwe łącze 2 × 1 Gbit/s na serwer, nielimitowany wolumen bez dławienia, stała cena miesięczna niezależna od przesłanej ilości danych oraz ochrona przed zalewaniem o wydajności 3,2 Tbps od razu po uruchomieniu. Serwer jest udostępniany w niecałe 30 sekund, z pełnym dostępem root, IPv4 i siecią IPv6 /64. Rozliczenie działa na zasadzie przedpłaty z możliwością rezygnacji co miesiąc, możesz więc zacząć od małej taryfy i rosnąć wtedy, gdy rośnie Twoja publiczność.