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). HLS-плеєр завантажує мастер-плейліст, аналізує доступні варіанти та починає відтворення з найбільш підхідного бітрейту. В процесі відтворення плеєр постійно моніторить швидкість завантаження сегментів та буфер заповнення, приймаючи рішення про перемикання на більш високий або низький бітрейт. Сучасні ABR-алгоритми враховують не лише швидкість мережі, але й розмір буфера, тип контенту та навіть енергоспоживання пристрою.

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

Розуміння структури HLS-потоку необхідне для коректного налаштування кодування, розподілу та налагодження проблем відтворення. Кожен HLS-потік складається з двох рівнів плейлістів та множини медіа-сегментів, організованих у сувору ієрархію.

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

Master playlist — це точка входу для HLS-плеєра. Файл з розширенням .m3u8 містить посилання на всі варіанти потоку та їх характеристики. Плеєр завантажує цей файл першим і на основі інформації про бітрейти та роздільності приймає початкове рішення про вибір варіанту. Мастер-плейліст також може містити посилання на альтернативні аудіодоріжки, субтитри та 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 — повний список всіх сегментів) або динамічно оновлюваним (для live-трансляцій — старі сегменти видаляються, нові додаються).

#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 для live-трансляцій. Навіть з 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, що дозволяє кешувати контент на проміжних проксі-серверах операторів зв'язку.