HLS-стримінг з мобільного — задача нетривіальна. Телефон виступає джерелом: записує відео сегментами, завантажує їх на HTTP-сервер та оновлює m3u8-плейлист. На відміну від відтворення HLS, тут важливо забезпечити стабільний захват, швидке пакування в TS та надійне завантаження. Ми реалізуємо такі проекти під ключ: від вибору протоколу до інтеграції з CDN. Нижче розберемо технічні деталі.
Як працює HLS-push з пристрою
Класична схема: телефон → HTTP PUT/POST TS-сегментів + оновлення .m3u8 → origin HTTP сервер → CDN → глядачі. Альтернатива: телефон → RTMP → медіасервер → HLS для глядачів (тоді HLS генерує сервер, не телефон). Прямий HLS-push підтримують: Apple Media Stream Segmenter (тільки macOS), CloudFront з WebDAV, Akamai Media Services, а також власний nginx з ngx_http_dav_module. Ми віддаємо перевагу настроюваному origin-серверу, оскільки це дає повний контроль над затримкою та форматом сегментів.
Порівняння підходів на iOS та Android
| Платформа | Інструмент | Кодувальник | Формат сегментів | Надійність | Затримка |
|---|---|---|---|---|---|
| iOS | FFmpegKit (h264_videotoolbox) | Апаратний H.264 | MPEG-TS | Висока | 6–30 с (стандарт) / 2–4 с (LL-HLS через сервер) |
| iOS | Кастомний TS-сегментер | Апаратний H.264 | MPEG-TS (ручна PES/PMT) | Середня (помилки пакування) | Аналогічно |
| Android | FFmpegKit (h264_mediacodec) | Апаратний H.264 | MPEG-TS або fMP4 | Висока | 6–30 с |
| Android | MediaMuxer з fMP4 | Апаратний H.264 | fMP4 (HLS v7+) | Низька (нестандартно) | Вище через буферизацію |
Чому варто обирати прямий HLS-push замість RTMP?
RTMP — протокол з постійним з'єднанням, що потребує сервера-ретранслятора (наприклад, Nginx-RTMP). Це додає ланку та збільшує затримку. Прямий HLS-push працює поверх HTTP, що дозволяє безпосередньо відправляти сегменти в CDN (Akamai, CloudFront). Мінус — потрібен розумніший клієнтський код для пакування в TS та завантаження. Наш досвід показує: для live-стримів з аудиторією до 10 000 глядачів HLS-push працює стабільніше та дешевше, ніж RTMP+CDN. Економія на інфраструктурі може сягати 30–40%.
Як реалізувати HLS-стримінг на iOS?
На iOS немає вбудованого HLS-енкодера для live — тільки AVAssetExportSession для файлів. Для live HLS будуємо pipeline вручну:
AVCaptureSession → AVCaptureVideoDataOutput → VideoToolbox (encode H.264) → накопичуємо NAL units в TS-сегменти по 2-4 секунди → URLSession.uploadTask на сервер → оновлюємо m3u8 маніфест Збірка MPEG-TS з NAL units — ручне пакування PES пакетів з PAT/PMT таблицями. Готової бібліотеки на Swift немає. Тому на практиці використовуємо FFmpegKit:
-f avfoundation -i 0:0 -c:v h264_videotoolbox -b:v 2M -hls_time 2 -hls_list_size 5 -hls_flags delete_segments -method PUT http://origin/stream/index.m3u8 h264_videotoolbox — апаратний кодувальник. Флаг -method PUT завантажує сегменти та плейлист на сервер. Працює, навантаження на CPU помірне.
Що таке Low-Latency HLS і коли він потрібен?
Стандартний HLS — затримка 6–30 секунд. LL-HLS знижує до 2–4 секунд за рахунок EXT-X-PART директив (представлено Apple на WWDC). З мобільного пристрою генерувати LL-HLS частини (тривалістю 0.2–0.5 с) надзвичайно складно без спеціалізованого енкодера. Практичніше: пристрій пушить RTMP з малим буфером, медіасервер (Nimble Streamer, Wowza) з LL-HLS плагіном генерує потік для глядачів. Це перевірене рішення, яке ми рекомендуємо, якщо затримка критична.
Порівняння схем: прямий HLS-push vs RTMP+сервер
| Критерій | Прямий HLS-push | RTMP + медіасервер |
|---|---|---|
| Затримка | 6–30 с (стандарт) | 8–35 с (з урахуванням ретрансляції) |
| Інфраструктура | Origin HTTP сервер | RTMP-сервер (Nginx-RTMP, Wowza) |
| Складність клієнта | Висока (сегментування) | Середня (RTMP-пушинг) |
| CDN-інтеграція | Напряму (PUT-запити) | Через сервер-ретранслятор |
| Стійкість до збоїв | Висока (HTTP простіше кешувати) | Середня (RTMP-з'єднання повинно бути постійним) |
Що входить в реалізацію HLS-стримінгу під ключ
- Аналіз вимог: бітрейт, роздільна здатність, цільова аудиторія, CDN.
- Вибір схеми: прямий HLS-push або RTMP → сервер.
- Розробка клієнтського додатку: iOS (Swift + FFmpegKit) або Android (Kotlin + FFmpegKit).
- Налаштування origin-сервера: nginx з DAV-модулем або сторонній CDN (Akamai, CloudFront).
- Тестування: навантажувальне, перевірка затримки, стабільності при слабкому сигналі.
- Документація та навчання: опис інтеграції, налаштування provisioning profile для сповіщень (push) та фонових завдань.
Apple HLS Authoring Specification
Докладніше про налаштування origin-сервера
Для організації origin-сервера часто використовуємо nginx з модулем ngx_http_dav_module. Конфігурація дозволяє приймати PUT-запити від пристрою та роздавати TS-сегменти і m3u8-плейлист. Приклад блоку location: /stream { dav_methods PUT; dav_access user:rw group:rw; }Процес роботи
- Аналітика: визначаємо протокол, необхідну затримку, ємність сховища на сервері.
- Проектування: схема pipeline (захоплення → кодування → сегментування → завантаження → маніфест).
- Реалізація: пишемо код на Swift/Kotlin, інтегруємо FFmpegKit.
- Тестування: на реальних пристроях (iPhone 12, Pixel 6) з різними бітрейтами та мережами.
- Деплой: викладка в App Store / Google Play, налаштування сервера, моніторинг.
Строки орієнтовно
Реалізація через FFmpegKit з завантаженням на origin — від 2 до 3 днів. Кастомний TS-сегментер та LL-HLS — від 1 до 2 тижнів. Точні строки залежать від складності інтеграції (кількість бітрейтів, підтримка фонового стримінгу).
Типові помилки та як їх уникнути
- Ігнорування Push Notifications: для HLS-push в фоні потрібно правильно налаштувати
Background Modes(iOS) таForeground Service(Android). - Неправильний таймінг сегментів: сегменти більше 6 секунд збільшують затримку та ризик переривання на стороні глядача.
- Відсутність обробки помилок завантаження: HTTP 4xx/5xx повинні приводити до повторної відправки сегмента з експоненційною затримкою.
- Нехтування таблицями PAT/PMT: при ручному збиранні TS будь-яка помилка робить потік нечитабельним для плеєрів.
Наш досвід — 5+ років у мобільному стримінгу та понад 10 реалізованих проектів. Отримайте консультацію для оцінки вашого проекту. Зв'яжіться з нами — ми безкоштовно проаналізуємо вимоги та запропонуємо оптимальну архітектуру HLS-стримінгу з мобільного пристрою. Гарантуємо стабільну роботу та дотримання App Store Review Guidelines (iOS) та Google Play Політики.