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 Политики.