HLS: co to jest, protokół i zasada działania

Co to jest HLS?

HTTP Live Streaming (HLS) — to protokół strumieniowego przesyłania mediów opracowany przez Apple w 2009 roku i po raz pierwszy przedstawiony w iOS 3.0 i Safari. W 2017 roku protokół został zaproponowany jako standard internetowy poprzez RFC 8216, co potwierdziło jego status otwartej specyfikacji dostępnej do implementacji na dowolnych platformach.

Główna idea HLS polega na podziale ciągłego strumienia mediów na krótkie segmenty o długości 2-10 sekund. Każdy segment stanowi samodzielny plik, który może być pobrany za pomocą zwykłego żądania HTTP. Zarządzanie strumieniem odbywa się za pomocą tekstowych playlist w formacie M3U8, które zawierają linki do segmentów i metadane potrzebne do ich prawidłowego odtwarzania.

Adaptacyjność — to kluczowa zaleta HLS. Serwer przygotowuje kilka wersji tej samej treści z różnymi przepływnościami — od 200 Kbps dla słabych połączeń do 20+ Mbps dla wideo 4K. Klient automatycznie wybiera odpowiednią przepływność na podstawie aktualnej przepustowości kanału. Według badań Apple (WWDC 2024), LL-HLS skraca czas przełączania między przepływnościami do 500 milisekund, zapewniając płynną zmianę jakości bez zauważalnych przerw.

Historia rozwoju HLS

Pierwsza wersja HLS (2009) obsługiwała tylko segmenty MPEG-2 TS z kodekiem audio AAC i kodekiem wideo H.264. W iOS 8 (2014) dodano obsługę segmentów fMP4 (fragmented MP4), co umożliwiło użycie HLS z nowocześniejszymi kodekami, w tym HEVC (H.265). iOS 11 (2017) wprowadził obsługę HDR10 i Dolby Vision. iOS 13 (2019) wprowadził Low-Latency HLS, zmniejszając opóźnienie z tradycyjnych 6-30 sekund do 2-6 sekund.

W 2023 roku Apple rozszerzyło HLS obsługą kodeków AV1 i EVC (Essential Video Coding), a także wdrożyło Content Steering — mechanizm dynamicznego przekierowywania klientów między serwerami CDN w celu optymalnego ładowania. Content Steering pozwala serwerowi zmieniać URL-e segmentów w locie, przekierowując klienta do najbliższego lub najmniej obciążonego węzła CDN bez przerywania odtwarzania.

Jak działa HLS?

Architektura HLS składa się z trzech głównych komponentów: część serwerowa (origin-server + enkoder), sieć dystrybucyjna (CDN) i część kliencka (odtwarzacz z obsługą HLS). Cały proces — od przechwycenia wideo do odtworzenia na urządzeniu użytkownika — obejmuje kilka kolejnych etapów, z których każdy jest krytyczny dla jakości streamingu.

Kodowanie i segmentacja

Źródłowe wideo jest najpierw kodowane w kilka wariantów z różnymi przepływnościami i rozdzielczościami. Profesjonalne enkodery, takie jak FFmpeg czy AWS Elemental MediaConvert, jednocześnie tworzą 4-12 wariantów strumienia: od 240p (400 Kbps) do 4K (40 Mbps). Każdy wariant jest cięty na segmenty o jednakowej długości, zwykle 2-6 sekund dla LL-HLS lub 6-10 sekund dla tradycyjnego HLS.

Dla każdego wariantu tworzona jest playlista medialna (variant playlist), zawierająca URL-e wszystkich segmentów i ich czas trwania. Dodatkowo tworzona jest playlista główna (master playlist), która łączy wszystkie warianty i zawiera informacje o każdym z nich: rozdzielczość, przepływność, kodek i ścieżki audio. Klient najpierw ładuje playlistę główną, a następnie wybiera odpowiedni wariant na podstawie analizy prędkości połączenia.

Dostawa przez CDN

Segmenty i playlisty są buforowane na serwerach CDN, rozmieszczonych geograficznie blisko użytkowników. Użycie standardowego protokołu HTTP do dostawy daje HLS krytyczną przewagę: każdy CDN, load balancer czy serwer proxy obsługujący HTTP działa z HLS bez dodatkowej konfiguracji. To odróżnia HLS od protokołów czasu rzeczywistego, takich jak RTMP czy WebRTC, które wymagają specjalistycznych serwerów.

import subprocess

subprocess.run([
    "ffmpeg",
    "-i", "input.mp4",
    "-codec:v", "libx264",
    "-codec:a", "aac",
    "-hls_time", "6",
    "-hls_list_size", "0",
    "-var_stream_map", "v:0,a:0 v:1,a:1",
    "-map", "v:0", "-b:v:0", "5000k",
    "-map", "v:1", "-b:v:1", "1000k",
    "-f", "hls",
    "stream/output.m3u8"
])

Strona kliencka używa algorytmu wyboru przepływności (ABR — Adaptive Bitrate). Odtwarzacz HLS ładuje playlistę główną, analizuje dostępne warianty i rozpoczyna odtwarzanie od najbardziej odpowiedniej przepływności. Podczas odtwarzania odtwarzacz stale monitoruje prędkość ładowania segmentów i stan bufora, podejmując decyzję o przełączeniu na wyższą lub niższą przepływność. Nowoczesne algorytmy ABR uwzględniają nie tylko prędkość sieci, ale także rozmiar bufora, typ treści, a nawet zużycie energii urządzenia.

Struktura strumienia HLS: playlisty i segmenty

Zrozumienie struktury strumienia HLS jest niezbędne do prawidłowej konfiguracji kodowania, dystrybucji i debugowania problemów z odtwarzaniem. Każdy strumień HLS składa się z dwóch poziomów playlist i wielu segmentów medialnych, zorganizowanych w ścisłą hierarchię.

Master Playlist (playlista główna)

Master playlist — to punkt wejścia dla odtwarzacza HLS. Plik z rozszerzeniem .m3u8 zawiera linki do wszystkich wariantów strumienia (variant streams) i ich charakterystyki. Odtwarzacz ładuje ten plik jako pierwszy i na podstawie informacji o przepływnościach i rozdzielczościach podejmuje początkową decyzję o wyborze wariantu. Playlista główna może również zawierać linki do alternatywnych ścieżek audio, napisów i playlist I-Frame do szybkiego przewijania.

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/video.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1000000,RESOLUTION=640x360
360p/video.m3u8

Media Playlist (playlista medialna)

Media playlist zawiera bezpośrednio listę segmentów dla jednego wariantu strumienia. Każdy segment jest podawany z czasem trwania i URI. Playlista medialna może być statyczna (dla VOD — pełna lista wszystkich segmentów) lub dynamicznie aktualizowana (dla transmisji na żywo — stare segmenty są usuwane, nowe dodawane).

#EXTM3U
#EXT-X-TARGETDURATION:6
#EXTINF:6.000,
segment001.ts
#EXTINF:6.000,
segment002.ts
#EXT-X-ENDLIST

Formaty segmentów

HLS obsługuje dwa główne formaty segmentów medialnych: MPEG-2 Transport Stream (.ts) i Fragmented MP4 (.m4s lub .mp4). MPEG-2 TS — oryginalny format HLS, zapewniający maksymalną kompatybilność. fMP4 — nowocześniejszy format, obsługujący HDR, HEVC i bardziej efektywną kompresję. Apple zaleca fMP4 dla wszystkich nowych projektów począwszy od iOS 10 i macOS Sierra.

Dodatkowe elementy strumienia HLS obejmują playlisty I-Frame do szybkiego przewijania, metadane ID3 do synchronizacji napisów i znaczników reklamowych, a także Session Data do przesyłania informacji o odtwarzaniu na serwer analityczny. Wszystkie te elementy są opcjonalne, ale ich użycie poprawia jakość doświadczenia użytkownika.

Zalety i wady HLS

HLS dominuje na rynku streamingu wideo dzięki szeregowi zalet architektonicznych, ale ma też ograniczenia, które należy uwzględnić przy wyborze protokołu dla konkretnego projektu. Porównajmy HLS z alternatywnymi protokołami dostawy wideo.

Główną zaletą HLS jest natywna obsługa na wszystkich urządzeniach Apple (iPhone, iPad, Apple TV, Mac) przez wbudowany AVPlayer. To czyni HLS standardem de facto dla aplikacji iOS/macOS. Ponadto użycie standardowego HTTP do dostawy pozwala buforować treść na dowolnych CDN i serwerach proxy bez dodatkowej konfiguracji, co znacznie upraszcza infrastrukturę dostawy.

Wady HLS obejmują wyższe opóźnienie w porównaniu z RTMP lub WebRTC dla transmisji na żywo. Nawet z LL-HLS minimalne opóźnienie wynosi 2-6 sekund, co jest nieakceptowalne dla interaktywnych scenariuszy w czasie rzeczywistym. Ponadto HLS generuje więcej plików na serwerze (każdy segment to osobny plik), co może obciążać system plików przy dużej liczbie równoczesnych transmisji.

HLS w aplikacjach mobilnych

Integracja HLS w aplikacjach mobilnych różni się w zależności od platformy. Na iOS i macOS HLS jest obsługiwany na poziomie systemu operacyjnego przez AVFoundation i AVPlayer, co zapewnia sprzętowe przyspieszenie dekodowania i minimalne zużycie energii. Na Androidzie HLS nie jest obsługiwany przez wbudowany MediaPlayer, ale jest dostępny przez ExoPlayer — oficjalny odtwarzacz medialny od Google.

HLS na iOS przez AVPlayer

Na platformie Apple odtwarzanie HLS jest maksymalnie proste dzięki wbudowanej obsłudze w AVPlayer. Wystarczy utworzyć AVPlayer z URL-em playlisty głównej, a system automatycznie obsłuży adaptacyjne przełączanie przepływności, wybór ścieżek audio i obsługę napisów. Developer ma przy tym dostęp do pełnej kontroli nad odtwarzaniem przez AVPlayerItem i AVAssetResourceLoader.

import AVFoundation

let url = URL(string: "https://example.com/stream.m3u8")!
let player = AVPlayer(url: url)
let controller = AVPlayerViewController()
controller.player = player
present(controller, animated: true) {
    player.play()
}

HLS na Androidzie przez ExoPlayer

Dla Androida używany jest ExoPlayer, który obsługuje HLS przez osobny moduł rozszerzenia. ExoPlayer zapewnia bardziej precyzyjną kontrolę nad strumieniem HLS: można zarządzać wyborem przepływności, konfigurować buforowanie i indywidualnie obsługiwać błędy ładowania segmentów. Dla LL-HLS wymagana jest wersja ExoPlayer 2.14.0 i wyższa.

val player = ExoPlayer.Builder(this).build()

val uri = Uri.parse("https://example.com/stream.m3u8")
val mediaItem = MediaItem.fromUri(uri)

player.setMediaItem(mediaItem)
player.prepare()
player.play()

Optymalizacja HLS dla sieci mobilnych

Aplikacje mobilne wymagają szczególnego podejścia do konfiguracji HLS ze względu na niestabilność sieci komórkowych i ograniczenia transferu danych. Główne zalecenia obejmują: ustawienie początkowej przepływności na podstawie typu sieci (Wi-Fi lub komórkowa), użycie krótszego czasu trwania segmentów (2-4 sekundy) dla szybszej adaptacji, wstępne ładowanie bufora przy przełączaniu na Wi-Fi i priorytetyzację ścieżki audio przy słabym sygnale.

Apple w dokumentacji HLS Authoring Specification for Apple Devices (2024) zaleca stosowanie rozmiaru segmentów nie większego niż 6 sekund dla urządzeń mobilnych i co najmniej 4 wariantów przepływności. W celu oszczędzania transferu w sieciach mobilnych serwer powinien dostarczać segmenty z nagłówkiem HTTP Cache-Control, umożliwiającym buforowanie treści na pośrednich serwerach proxy operatorów komórkowych.