HLS (HTTP Live Streaming) – jak działa ten protokół streamingu wideo?

Protokół HLS (HTTP Live Streaming) działa poprzez dzielenie ciągłego strumienia wideo na serię małych, kilkusekundowych plików pobieranych przez odtwarzacz za pomocą standardowego protokołu HTTP. Główny mechanizm opiera się na pliku indeksowym (manifest .m3u8), który instruuje przeglądarkę, skąd pobrać kolejne fragmenty i w jakiej rozdzielczości odtworzyć je w zależności od aktualnej prędkości internetu użytkownika.

Strumieniowanie mediów w sieci urosło do rangi podstawowego kanału komunikacji z klientem. My na wdrożeniach widzimy codziennie, jak źle skonfigurowane serwery wideo potrafią zabić ruch na stronie. Prawda jest zresztą absolutnie taka, że wielu administratorów wrzuca po prostu plik MP4 na serwer FTP i ma nadzieję, że przeglądarka jakoś to przetrawi. To jest błąd. Zwykłe pobieranie pliku wideo blokuje wątki i marnuje transfer. Apple w 2009 roku rozwiązało ten problem, tworząc architekturę opartą na starych, dobrych żądaniach sieciowych. Zmieniliśmy te zasady na robocie lata temu, przechodząc w całości na segmentację.

Co to jest protokół HLS i do czego służy w praktyce?

HTTP Live Streaming to technologia dostarczania obrazu i dźwięku przez internet wymyślona przez inżynierów z Cupertino. Pierwotnie miała obsługiwać wczesne generacje iPhone’ów, które miały ogromny kłopot z utrzymaniem stabilnego połączenia w sieciach 3G. Zamiast pchać jeden, ciężki strumień danych przez egzotyczne protokoły takie jak RTMP czy RTSP, Apple postawiło na prostotę. Wykorzystano architekturę, która już istniała i działała bezbłędnie we wszystkich firewallach na świecie. Port 80 i 443.

Zastosowanie tej technologii dzieli się na dwa główne nurty:

• Transmisje na żywo (Live Streaming): Wydarzenia sportowe, webinary, kanały telewizyjne w internecie. Manifest aktualizuje się w czasie rzeczywistym, dodając na koniec listy nowe wygenerowane fragmenty. Odtwarzacz cały czas odpytuje serwer o nową wersję pliku tekstowego, by wiedzieć, co ma pobrać za chwilę.
• Wideo na żądanie (VOD): Filmy i seriale na platformach streamingowych. W tym przypadku lista plików jest statyczna i zamknięta. Odtwarzacz widzi od razu cały czas trwania materiału i swobodnie przeskakuje między segmentami, gdy użytkownik przesuwa pasek postępu.

Protokół przyjął się tak mocno, że zdominował rynek. (Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek, kiedy nowy odtwarzacz gubił klatki kluczowe przy przełączaniu jakości). Odtwarzacze HTML5 w natywny sposób radzą sobie z tym formatem w przeglądarkach Safari i Edge, a w Chrome i Firefox używa się lekkich bibliotek JavaScript, takich jak hls.js lub Video.js.

Jak technicznie działa HTTP Live Streaming?

Architektura całego zjawiska opiera się na trzech głównych filarach. Brakuje tu magii. To brutalna, matematyczna segmentacja i ciągłe odpytywanie serwera o pliki tekstowe. System musi najpierw przygotować dane, zanim wyśle je w świat.

Faza pierwsza: Kodowanie i segmentacja wideo

Kamera lub oprogramowanie nadawcze (np. OBS Studio) wysyła surowy sygnał wideo do serwera. Tam do gry wchodzi enkoder. Zazwyczaj jest to FFmpeg lub sprzętowe układy kodujące. Enkoder kompresuje obraz używając popularnych kodeków, najczęściej H.264 lub nowszego H.265 (HEVC). Dźwięk pakuje się w format AAC. To jednak dopiero początek procesu.

Zaraz za enkoderem stoi pakietyzator (packager). Jego zadaniem jest poszatkowanie ciągłego strumienia na krótkie pliki. Kiedyś używano wyłącznie kontenera MPEG-TS (.ts). Obecnie zdecydowana większość systemów korzysta ze sfragmentaryzowanego formatu MP4 (fMP4). Każdy taki plik trwa zazwyczaj od 2 do 10 sekund. Długość segmentu to decyzja administratora. Krótsze fragmenty obniżają opóźnienia. Dłuższe oszczędzają moc obliczeniową procesora i zmniejszają narzut na nagłówki HTTP.

Faza druga: Generowanie manifestów .m3u8

Same pliki wideo nic nie znaczą bez mapy drogowej. Tą mapą są pliki manifestu z rozszerzeniem .m3u8. To zwykłe pliki tekstowe zakodowane w UTF-8. Zawierają tagi informujące aplikację, z czym ma do czynienia. Architektura manifestów jest dwupoziomowa.

Master Playlist (Manifest główny) to pierwszy plik, jaki pobiera aplikacja. Zamiast linków do wideo, zawiera linki do innych manifestów. Każdy z tych podrzędnych manifestów odpowiada za inną rozdzielczość i przepływność (bitrate). Tabela poniżej pokazuje, jak wygląda typowy podział jakościowy na serwerze.

Media Playlist (Manifest wariantowy) to już konkretna lista plików do pobrania. Jeśli przeglądarka uzna, że ma dobre łącze, wchodzi w manifest 1080p. Tam widzi listę plików: segment_001.ts, segment_002.ts. Pobiera je po kolei.

Faza trzecia: Serwery brzegowe (CDN)

To tutaj HLS ujawnia swoją przewagę nad starszymi technologiami. Ponieważ strumień to w rzeczywistości tysiące małych plików, można je idealnie cachować. Nie potrzebujemy drogich, dedykowanych serwerów strumieniujących. Wystarczy zwykły serwer WWW (Nginx, Apache) połączony z siecią Content Delivery Network (CDN).

Kiedy tysiąc użytkowników w Warszawie chce oglądać ten sam mecz, serwer główny w Londynie wysyła segmenty tylko raz do węzła w Polsce. Węzeł brzegowy CDN zapisuje te pliki w pamięci RAM. Wszyscy klienci w Warszawie pobierają pliki już z lokalnego serwera. Skalowalność tego rozwiązania jest praktycznie nieskończona. Wystarczy dokładać kolejne węzły proxy. Tak to działa.

Czym jest Adaptive Bitrate Streaming (ABR) w HLS?

Oglądasz film w pociągu. Wyjeżdżasz z miasta, zasięg 5G spada do słabego LTE, a potem do 3G w lesie. Stare odtwarzacze po prostu zatrzymałyby obraz i wyświetliły ikonę ładowania. HLS radzi sobie z tym inaczej dzięki mechanizmowi Adaptive Bitrate.

Odtwarzacz na twoim telefonie to sprytny algorytm. Podczas pobierania pierwszego segmentu z listy, mierzy dokładnie czas, jaki upłynął od wysłania żądania GET do odebrania ostatniego bajtu pliku. Na tej podstawie oblicza aktualną przepustowość łącza. Jeśli pobranie dwusekundowego fragmentu w jakości 1080p zajęło mu trzy sekundy, wie, że ma problem. Łącze jest wolniejsze niż bitrate wideo. Bufor zaraz się opróżni.

Algorytm podejmuje natychmiastową decyzję. Wraca do pliku Master Playlist. Wybiera z niego strumień o niższej jakości, na przykład 480p. Kolejny segment pobiera już z nowej, lżejszej listy. Obraz na ekranie staje się na chwilę mniej ostry, ale odtwarzanie nie przerywa się ani na sekundę. Gdy pociąg wyjedzie z lasu i łącze przyspieszy, odtwarzacz ponownie przeliczy transfer i automatycznie wróci do jakości Full HD. To jest bez mała najlepsza metoda na utrzymanie retencji widzów.

Jakie są różnice między HLS a MPEG-DASH?

Rynek strumieniowania podzielił się na dwa obozy. Z jednej strony mamy protokół od Apple, z drugiej otwarty standard MPEG-DASH (Dynamic Adaptive Streaming over HTTP). Obie technologie działają na bardzo zbliżonej zasadzie. Obie tną pliki na kawałki i wykorzystują ABR. Diabeł tkwi w szczegółach inżynieryjnych.

DASH nie korzysta z plików .m3u8. Zamiast tego używa rozbudowanych manifestów XML z rozszerzeniem .mpd. Są one trudniejsze do ręcznego czytania przez człowieka, ale dają maszynom więcej metadanych. Druga kwestia to agnostyczność kodeków. O ile specyfikacja Apple mocno faworyzuje konkretne formaty kontenerów i kodeki, MPEG-DASH pozwala wrzucić do środka niemal wszystko, łącznie z niszowymi formatami audio i wideo. Wymaga to jednak od przeglądarki posiadania odpowiednich dekoderów.

Z punktu widzenia biznesowego, HLS wygrywa kompatybilnością. Jeśli chcesz dotrzeć do posiadaczy iPhone’ów, iPadów i przystawek Apple TV, musisz mieć ten format. Systemy z logo nadgryzionego jabłka mają tendencję do blokowania lub utrudniania odtwarzania DASH w natywnych aplikacjach. My z reguły konfigurujemy na serwerach paczkowanie do obu formatów naraz. Używamy tych samych fragmentów wideo (.m4s) pod spodem, generując po prostu dwa różne manifesty tekstowe. Kosztuje to niewiele miejsca na dysku, a załatwia sprawę z każdym urządzeniem na rynku.

Czy HLS ma duże opóźnienia podczas transmisji na żywo?

Tak. Standardowa implementacja tego protokołu jest wolna. Bardzo wolna. Kiedy sąsiad ogląda mecz w telewizji kablowej i krzyczy po strzelonej bramce, ty w internecie zobaczysz ten strzał dopiero za 30 sekund. To największa bolączka segmentacji HTTP.

Opóźnienie (latencja) wynika z samej fizyki protokołu. Zobaczmy, gdzie tracimy czas na standardowych ustawieniach:

• Kamera i enkoder potrzebują około 2 sekund na skompresowanie obrazu i zbudowanie grupy klatek (GOP).
• Pakietyzator musi zamknąć segment. Jeśli ustawiłeś segmenty na 6 sekund, serwer musi czekać pełne 6 sekund, zanim zapisze plik na dysku i dopisze go do manifestu. Mamy już 8 sekund.
• Odtwarzacz po stronie użytkownika ma wbudowane zasady bezpieczeństwa. Zgodnie z wytycznymi, aplikacja powinna pobrać co najmniej 3 segmenty do lokalnego bufora, zanim w ogóle rozpocznie wyświetlanie pierwszej klatki. Trzy segmenty po 6 sekund to 18 sekund buforowania.
• Doliczmy do tego propagację plików przez serwery CDN na różnych kontynentach. Czas leci.

W klasycznym ujęciu latencja na poziomie 20-30 sekund jest normą. Do oglądania wiadomości to nie przeszkadza. Do interaktywnych webinarów, kasyn online czy licytacji na żywo – to absolutna katastrofa biznesowa. Zwykłe wejście z czatem obok wideo traci jakikolwiek sens, gdy prowadzący odpowiada na pytania z półminutowym poślizgiem.

Low-Latency HLS (LL-HLS) – odpowiedź na problem latencji

Apple zauważyło problem i w 2019 roku ogłosiło specyfikację Low-Latency HLS. Celem było zejście z opóźnieniami poniżej 3 sekund, przy zachowaniu wszystkich zalet skalowania przez CDN. Rozwiązanie tego problemu wymagało mocnych zmian w architekturze serwerów.

Zamiast czekać na wygenerowanie całego 6-sekundowego segmentu, LL-HLS dzieli go na mikro-fragmenty (parts). Mają one ułamki sekund. Serwer nie czeka na zamknięcie dużego pliku. Natychmiast wysyła gotowy ułamek do odtwarzacza za pomocą mechanizmu Chunked Transfer Encoding w HTTP. Odtwarzacz zaczyna dekodować i wyświetlać obraz, podczas gdy reszta segmentu jeszcze się pobiera.

Dodatkowo wdrożono mechanizm blokowania żądań (Manifest Blocking). Odtwarzacz pyta serwer o nową listę plików, ale dodaje parametr: „odpowiedz mi dopiero, gdy pojawi się nowy fragment”. Dzięki temu unikamy setek pustych zapytań, które tylko obciążały łącza. LL-HLS wymaga jednak bardzo nowoczesnej infrastruktury CDN obsługującej HTTP/2. Nie każdy dostawca hostingu potrafi to prawidłowo wdrożyć od ręki.

Jak wdrożyć HLS na własnym serwerze krok po kroku

Zostawmy teorię. Pokażę ci, jak wygenerować strumień samodzielnie u siebie na lokalnym komputerze lub serwerze VPS. Będziemy potrzebować darmowego narzędzia FFmpeg działającego z linii komend. To potężny kombajn do obróbki wideo.

Załóżmy, że masz na dysku plik wideo o nazwie „moj_film.mp4” i chcesz go udostępnić w internecie w formie paczek HLS. Otwierasz terminal i wpisujesz komendę. Musisz wskazać plik wejściowy, kodek wideo, kodek audio, czas trwania segmentu oraz nazwę manifestu wyjściowego.

Polecenie w terminalu wygląda tak: ffmpeg -i moj_film.mp4 -codec:v libx264 -codec:a aac -hls_time 4 -hls_playlist_type vod -hls_segment_filename "segment_%03d.ts" strumien.m3u8

Co tu się właśnie wydarzyło? Program bierze twój plik źródłowy. Konwertuje wideo używając biblioteki H.264, a dźwięk do AAC. Flaga -hls_time 4 wymusza cięcie pliku na kawałki o długości dokładnie czterech sekund. Typ playlisty VOD oznacza, że to zamknięty plik, a nie transmisja na żywo. Na koniec definiujemy schemat nazewnictwa dla poszczególnych paczek i nazwę głównego indeksu.

Po kilku minutach pracy procesora, w folderze zobaczysz kilkadziesiąt plików .ts oraz jeden plik strumien.m3u8. Wrzucasz cały ten katalog na swój serwer WWW, do katalogu publicznego. Na stronie HTML dodajesz prosty tag wideo i podpinasz bibliotekę hls.js. Przeglądarka wchodzi na stronę, pobiera plik tekstowy i zaczyna strumieniować twój materiał bez zacinania.

Struktura pliku M3U8 od środka

Otwórzmy wygenerowany plik w notatniku. Zrozumienie tych kilku linijek tekstu pozwala namierzyć 90% błędów podczas awarii na produkcji. Każdy plik zaczyna się od znacznika #EXTM3U, który informuje parser, że ma do czynienia z prawidłowym formatem. Poniżej znajduje się nagłówek #EXT-X-VERSION:3, określający wersję użytej specyfikacji Apple. Wyższe wersje wprowadzają nowe funkcje, takie jak szyfrowanie AES-128.

Dalej mamy #EXT-X-TARGETDURATION:4. To bardzo twarda deklaracja dla odtwarzacza. Mówi ona: „najdłuższy segment na tej liście trwa dokładnie 4 sekundy, przygotuj swój bufor pamięci na taką porcję danych”. Następnie widzimy tag #EXT-X-PLAYLIST-TYPE:VOD. Dzięki niemu aplikacja wie, że może wyrenderować pasek postępu (scrubber), bo strumień nie rośnie w czasie rzeczywistym.

Pod spodem zaczyna się właściwa lista. Znacznik #EXTINF:4.000, poprzedza nazwę pliku. Oznacza czas trwania konkretnego, pojedynczego segmentu zapisanego pod nim (np. segment_001.ts). I tak w kółko, aż do samego końca pliku. Jeśli to materiał VOD, na samym dole znajdziemy tag #EXT-X-ENDLIST. Gdy odtwarzacz go zobaczy, wie, że to koniec filmu. Jeśli tagu brakuje, aplikacja zakłada, że trwa transmisja na żywo i za kilka sekund odpyta serwer ponownie o nowe linijki tekstu u dołu.

Bezpieczeństwo i szyfrowanie strumieni

Wysyłanie plików wideo w czystej postaci to proszenie się o piractwo. Ktoś może użyć wtyczki do przeglądarki, pobrać wszystkie segmenty .ts, skleić je programem i wrzucić twój płatny kurs na forum. Protokół ma wbudowane natywne mechanizmy ochrony treści.

Najprostszym z nich jest AES-128. Enkoder podczas cięcia plików szyfruje każdy z nich kluczem symetrycznym. Do pliku manifestu dodaje się linijkę z adresem URL, pod którym znajduje się klucz deszyfrujący. Gdy przeglądarka pobierze zaszyfrowany segment wideo, odczytuje adres z manifestu, wysyła zapytanie o klucz, odszyfrowuje paczkę w locie i wyświetla obraz. Oczywiście adres klucza można zabezpieczyć tokenem autoryzacyjnym, by tylko zalogowani użytkownicy mogli go pobrać.

Dla dużych graczy biznesowych i wytwórni filmowych to za mało. Wykorzystuje się wtedy pełnoprawne systemy DRM (Digital Rights Management), takie jak Apple FairPlay, Google Widevine czy Microsoft PlayReady. W takim układzie klucze licencyjne są generowane dynamicznie przez serwery certyfikowane. Odtwarzacz musi udowodnić, że działa na bezpiecznym sprzęcie (np. niesłakowanym telefonie), zanim w ogóle dostanie pozwolenie na rozszyfrowanie pierwszej klatki wideo.

Wyzwanie dla administratorów

Zbudowanie własnej platformy wideo w oparciu o HLS to doskonały test kompetencji serwerowych. Przestań polegać na gotowych, drogich wtyczkach i zewnętrznych platformach, które pożerają twoją marżę. Zainstaluj FFmpeg. Weź testowy plik wideo z telefonu. Poszatkuj go na segmenty fMP4 z użyciem linii komend, wygeneruj manifest z trzema różnymi jakościami bitrate i zmuś prosty kod HTML z hls.js do płynnego przełączania jakości w przeglądarce pod wpływem dławienia sieci w DevToolsach. Zobaczysz na własne oczy, ile gigabajtów transferu zaoszczędzisz w pierwszym miesiącu działania produkcyjnego.

Bibliografia i źródła

1. Apple Developer Documentation – https://developer.apple.com
2. FFmpeg Official Project – https://ffmpeg.org
3. Internet Engineering Task Force (IETF) – https://www.ietf.org
4. Video.js Open Source Player – https://videojs.com
5. W3C Web Video Text Tracks – https://www.w3.org