___   _______  __   __  _______    _______  ______    _______  _______  _______
|   | |       ||  | |  ||       |  |       ||    _ |  |       ||       ||       |
|   | |_     _||  |_|  ||_     _|  |    _  ||   | ||  |    ___||  _____||  _____|
|   |   |   |  |       |  |   |    |   |_| ||   |_||_ |   |___ | |_____ | |_____
|   |   |   |  |       |  |   |    |    ___||    __  ||    ___||_____  ||_____  |
|   |   |   |   |     |   |   |    |   |    |   |  | ||   |___  _____| | _____| |
|___|   |___|    |___|    |___|    |___|    |___|  |_||_______||_______||_______|
      

Konteneryzacja Docker i stabilność platformy

Cała infrastruktura iTVT opiera się na zaawansowanej architekturze kontenerów Docker. W celu zapewnienia maksymalnej elastyczności i eliminacji ryzyk związanych ze stabilnością, system został podzielony na wyspecjalizowane, odizolowane usługi:

• Główny playout (serce systemu): Kontener oparty na technologii GStreamer, który odpowiada bezpośrednio za emisję sygnału – mikser wideo oraz audio dla kanału linearnego iTVT.
• Scheduler (zarządzanie): Dedykowany kontener, który umożliwia planowanie ramówki. Dzięki niemu playout automatycznie przełącza sceny, programy, zapowiedzi oraz bloki reklamowe.
• Broker-listener (obsługa reklam): Kontener odpowiedzialny za ciągły nasłuch i odbiór materiałów reklamowych od brokera zewnętrznego (poprzez standardy VAST/VMAP) lub bezpośrednio z plików lokalnych.
• Kanały FAST (izolacja): Każdy kanał typu FAST został wydzielony do osobnego, niezależnego kontenera, co zapobiega przenoszeniu się ewentualnych błędów i drastycznie zwiększa stabilność całego środowiska.

Nad całością systemu w celu zminimalizowania czasu ewentualnych przestojów oraz zagwarantowania najwyższej niezawodności, działa system monitoringu Uptime Kuma, który stale nadzoruje pracę wszystkich kontenerów.

Protokoły transmisyjne: SRT, RTMP, HLS

Serce platformy stanowią trzy protokoły transmisyjne:

• SRT (Secure Reliable Transport) — główny protokół transmisji na żywo. Charakteryzuje się odpornością na straty pakietów i niskim opóźnieniem.
• RTMP — protokół używany do ingestu strumienia z źródeł zewnętrznych.
• HLS (Low-Latency) — protokół dostarczania treści do przeglądarek i urządzeń mobilnych. Dzięki wdrożeniu nowoczesnej technologii bezpośredniej konwersji ze strumienia SRT na HLS, udało się zredukować opóźnienie (latency) w odtwarzaczu u widza w typowych warunkach sieciowych, zaledwie do 3-5 sekund, co zapewnia płynny odbiór sygnału w czasie zbliżonym do rzeczywistego.

Zaufane oprogramowanie w iTVT

W procesie emisji my oraz nasi partnerzy korzystamy ze sprawdzonych i powszechnie stosowanych rozwiązań, takich jak RevoStream, OBS Studio oraz vMix. W celu zapewnienia jeszcze wyższego poziomu bezpieczeństwa, większej stabilności, niższego opóźnienia oraz pełnej kompatybilności, nasz zespół planuje w przyszłości głębszą migrację całego ekosystemu w stronę autorskich rozwiązań.

Kluczowym krokiem w tej strategii jest rozwój modułu transmisyjnego RevoStream, który docelowo przepisywany jest w całości w języku Rust z wykorzystaniem biblioteki libobs-rs. Eliminacja surowych odwołań do C/C++ drastycznie zwiększyła stabilność renderowania oraz istotnie redukuje ryzyko błędów związanych z zarządzaniem pamięcią.
➤ Jak porzuciliśmy OBS Studio dla Rusta, czyli jak powstało RevoStream

Cały ekosystem streamingowy iTVT jest rygorystycznie optymalizowany pod kątem minimalnego zużycia zasobów przy maksymalnej wydajności sieciowej. Projektowany z myślą o wysokiej dostępności i niezawodności usług

MediaMTX — relay strumieni i nasze mechanizmy fallback

Do pośredniczenia między ingestem a dystrybucją wykorzystujemy MediaMTX — lekki serwer relayu strumieni, który przyjmuje dane przez SRT/RTMP i przekazuje je do klientów przez HLS.

W ramach podnoszenia niezawodności nadawania, eksperymentalnie wdrażamy zaawansowany system fallback na MediaMTX. W przypadku nagłego zerwania transmisji na serwerze głównym, system automatycznie przełącza źródło na sygnał zapasowy, dzięki czemu widz unika oglądania „czarnego ekranu”. Dodatkowo w najbliższej przyszłości planowane jest zaimplementowanie analogicznego mechanizmu fallback bezpośrednio po stronie playera, co zapewni podwójną warstwę ochrony przed przerwami w dostawie sygnału.

Infrastruktura sieciowa i zabezpieczenia Cloudflare

Zarządzanie ruchem na brzegu sieci (edge) oraz dystrybucja danych realizowane są z wykorzystaniem platformy Cloudflare. Architektura ta pozwala na skuteczne filtrowanie ruchu oraz optymalizację dostarczania treści:

• DNS, CDN i Reverse Proxy: Globalna sieć Anycast Cloudflare pozwala na redukcję opóźnień (TTFB) oraz odciążenie infrastruktury iTVT poprzez efektywne keszowanie statycznych zasobów platformy.
• Szyfrowanie HTTPS/TLS: Zastosowanie nowoczesnych standardów kryptograficznych w transmisji danych pomiędzy klientem a infrastrukturą sieciową znacząco zwiększa poufność oraz integralność przesyłanego strumienia.
• Ochrona DDoS i WAF: Aktywne reguły bezpieczeństwa pomagają wykrywać anomalie sieciowe na wczesnym etapie oraz ograniczać skutki ataków wolumetrycznych ataków na warstwę aplikacyjną, minimalizując ryzyko przerw w dostępności usług.
• Filtry aplikacyjne i ochrona strumienia: Wdrożone reguły cache'owania oraz polityki bezpieczeństwa warstwy aplikacyjnej utrudniają nieautoryzowane osadzanie (hotlinking) strumieni wideo, ograniczając możliwość ich odtwarzania poza oficjalnym playerem iTVT.

SSAI — monetyzacja reklam

System Server-Side Ad Insertion (SSAI) umożliwia płynną insertcję reklam po stronie serwera, bez wpływu na jakość transmisji dla widzów.
➤ Wdrożenie SSAI w kanałach linearnych iTVT