HLS: какво е това, протокол и принцип на работа

Какво е HLS?

HTTP Live Streaming (HLS) — е протокол за поточно предаване на медии, разработен от Apple през 2009 г. и представен за първи път в iOS 3.0 и Safari. През 2017 г. протоколът беше предложен като интернет стандарт чрез RFC 8216, което потвърди статуса му като отворена спецификация, достъпна за имплементация на всяка платформа.

Основната идея на HLS е разделянето на непрекъснатия медиен поток на кратки сегменти с продължителност 2-10 секунди. Всеки сегмент представлява самостоятелен файл, който може да бъде изтеглен чрез обикновена HTTP заявка. Управлението на потока се осъществява чрез текстови плейлисти във формат M3U8, които съдържат връзки към сегментите и метаданни за тяхното коректно възпроизвеждане.

Адаптивност — е ключовото предимство на HLS. Сървърът подготвя няколко версии на едно и също съдържание с различни битрейтове — от 200 Kbps за слаби връзки до 20+ Mbps за 4K видео. Клиентът автоматично избира подходящия битрейт въз основа на текущата честотна лента на канала. Според изследване на Apple (WWDC 2024) LL-HLS намалява времето за превключване между битрейтовете до 500 милисекунди, осигурявайки плавна промяна на качеството без забележими паузи.

История на развитие на HLS

Първата версия HLS (2009) поддържаше само MPEG-2 TS сегменти с аудио кодек AAC и видео кодек H.264. В iOS 8 (2014) беше добавена поддръжка за fMP4 (fragmented MP4) сегменти, което позволи използването на HLS с по-модерни кодеци, включително HEVC (H.265). iOS 11 (2017) представи поддръжка за HDR10 и Dolby Vision. iOS 13 (2019) въведе Low-Latency HLS, намалявайки латентността от традиционните 6-30 секунди на 2-6 секунди.

През 2023 г. Apple разшири HLS с поддръжка за кодеците AV1 и EVC (Essential Video Coding), а също така внедри Content Steering — механизъм за динамично пренасочване на клиенти между CDN сървъри за оптимално зареждане. Content Steering позволява на сървъра да променя URL адресите на сегментите в движение, пренасочвайки клиента към най-близкия или най-малко натоварения CDN възел без прекъсване на възпроизвеждането.

Как работи HLS?

Архитектурата на HLS се състои от три основни компонента: сървърна част (origin сървър + кодер), разпределителна мрежа (CDN) и клиентска част (плейър с поддръжка на HLS). Целият процес — от заснемане на видео до възпроизвеждане на устройството на потребителя — включва няколко последователни етапа, всеки от които е критичен за качеството на стрийминга.

Кодиране и сегментиране

Изходното видео първо се кодира в няколко варианта с различни битрейтове и разделителни способности. Професионалните кодери като FFmpeg или AWS Elemental MediaConvert едновременно създават 4-12 варианта на потока: от 240p (400 Kbps) до 4K (40 Mbps). Всеки вариант се нарязва на сегменти с еднаква продължителност, обикновено 2-6 секунди за LL-HLS или 6-10 секунди за традиционен HLS.

За всеки вариант се създава медиен плейлист (variant playlist), съдържащ URL адресите на всички сегменти и тяхната продължителност. Допълнително се създава мастер плейлист (master playlist), който обединява всички варианти и съдържа информация за всеки от тях: разделителна способност, битрейт, кодек и аудио писти. Клиентът първо изтегля мастер плейлиста, след което избира подходящия вариант въз основа на анализ на скоростта на връзката.

Доставка чрез CDN

Сегментите и плейлистите се кешират на CDN сървъри, разположени географски близо до потребителите. Използването на стандартния HTTP протокол за доставка дава на HLS критично предимство: всеки CDN, балансьор на натоварване или прокси сървър, поддържащ HTTP, работи с HLS без допълнителна конфигурация. Това отличава HLS от протоколите в реално време като RTMP или WebRTC, които изискват специализирани сървъри.

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"
])

Клиентската страна използва алгоритъм за избор на битрейт (ABR — Adaptive Bitrate). HLS плейърът изтегля мастер плейлиста, анализира наличните варианти и започва възпроизвеждане с най-подходящия битрейт. По време на възпроизвеждане плейърът непрекъснато следи скоростта на зареждане на сегментите и запълването на буфера, вземайки решение за превключване към по-висок или по-нисък битрейт. Съвременните ABR алгоритми вземат предвид не само скоростта на мрежата, но и размера на буфера, типа съдържание и дори консумацията на енергия на устройството.

Структура на HLS поток: плейлисти и сегменти

Разбирането на структурата на HLS потока е необходимо за правилно конфигуриране на кодирането, разпространението и отстраняване на проблеми с възпроизвеждането. Всеки HLS поток се състои от две нива плейлисти и множество медийни сегменти, организирани в строга йерархия.

Master Playlist (мастер плейлист)

Master playlist — е входната точка за HLS плейъра. Файлът с разширение .m3u8 съдържа връзки към всички варианти на потока (variant streams) и техните характеристики. Плейърът изтегля този файл първи и въз основа на информацията за битрейтовете и разделителните способности взема първоначално решение за избор на вариант. Мастер плейлистът може също да съдържа връзки към алтернативни аудио писти, субтитри и I-Frame плейлисти за бързо превъртане.

#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 (медиен плейлист)

Media playlist съдържа директно списъка със сегменти за един вариант на потока. Всеки сегмент се посочва с продължителност и URI. Медийният плейлист може да бъде статичен (за VOD — пълен списък на всички сегменти) или динамично актуализиран (за живи предавания — старите сегменти се премахват, нови се добавят).

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

Формати на сегменти

HLS поддържа два основни формата на медийни сегменти: MPEG-2 Transport Stream (.ts) и Fragmented MP4 (.m4s или .mp4). MPEG-2 TS — оригиналният формат на HLS, осигуряващ максимална съвместимост. fMP4 — по-модерен формат, поддържащ HDR, HEVC и по-ефективна компресия. Apple препоръчва fMP4 за всички нови проекти, започвайки от iOS 10 и macOS Sierra.

Допълнителни елементи на HLS потока включват I-Frame плейлисти за бързо превъртане, ID3 метаданни за синхронизиране на субтитри и рекламни маркери, както и Session Data за предаване на информация за гледане на аналитичния сървър. Всички тези елементи са опционални, но използването им подобрява качеството на потребителското изживяване.

Предимства и недостатъци на HLS

HLS доминира на пазара за видео стрийминг благодарение на редица архитектурни предимства, но има и ограничения, които трябва да се вземат предвид при избора на протокол за конкретен проект. Нека сравним HLS с алтернативни протоколи за доставка на видео.

Основното предимство на HLS — родна поддръжка на всички Apple устройства (iPhone, iPad, Apple TV, Mac) чрез вградения AVPlayer. Това прави HLS де факто стандарт за iOS/macOS приложения. Освен това, използването на стандартен HTTP за доставка позволява кеширане на съдържанието на всеки CDN и прокси сървър без допълнителна конфигурация, което значително опростява инфраструктурата за доставка.

Недостатъците на HLS включват по-висока латентност в сравнение с RTMP или WebRTC за живи предавания. Дори с LL-HLS минималната латентност е 2-6 секунди, което е неприемливо за интерактивни сценарии в реално време. Също така HLS генерира повече файлове на сървъра (всеки сегмент е отделен файл), което може да създаде натоварване на файловата система при голям брой едновременни предавания.

HLS в мобилни приложения

Интеграцията на HLS в мобилни приложения се различава в зависимост от платформата. На iOS и macOS HLS се поддържа на ниво операционна система чрез AVFoundation и AVPlayer, което осигурява хардуерно ускорение на декодирането и минимална консумация на енергия. На Android HLS не се поддържа от вградения MediaPlayer, но е достъпен чрез ExoPlayer — официалният медиен плейър от Google.

HLS на iOS чрез AVPlayer

На платформата Apple възпроизвеждането на HLS е изключително просто благодарение на вградената поддръжка в AVPlayer. Достатъчно е да създадете AVPlayer с URL адреса на мастер плейлиста и системата автоматично ще обработи адаптивното превключване на битрейтове, избора на аудио писти и обработката на субтитри. Разработчикът има достъп до пълен контрол върху възпроизвеждането чрез AVPlayerItem и 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 на Android чрез ExoPlayer

За Android се използва ExoPlayer, който поддържа HLS чрез отделен модул за разширение. ExoPlayer предоставя по-фин контрол върху HLS потока: може да се управлява изборът на битрейт, да се конфигурира буферирането и да се обработват грешки при зареждане на сегменти поотделно. За LL-HLS се изисква версия ExoPlayer 2.14.0 и по-висока.

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()

Оптимизация на HLS за мобилни мрежи

Мобилните приложения изискват специален подход към конфигурирането на HLS поради нестабилността на клетъчните мрежи и ограниченията на трафика. Основните препоръки включват: настройка на началния битрейт въз основа на типа мрежа (Wi-Fi или клетъчна), използване на по-кратка продължителност на сегментите (2-4 секунди) за по-бърза адаптация, предварително зареждане на буфера при превключване към Wi-Fi и приоритизиране на аудио пистата при слаб сигнал.

Apple в документацията HLS Authoring Specification for Apple Devices (2024) препоръчва използването на размер на сегментите не повече от 6 секунди за мобилни устройства и най-малко 4 варианта на битрейт. За пестене на трафик в мобилни мрежи сървърът трябва да доставя сегменти с HTTP заглавка Cache-Control, позволяваща кеширане на съдържанието на междинни прокси сървъри на телекомуникационните оператори.