Интеграция прямых трансляций (Live Streaming) в мобильное приложение
При попытке добавить live-стриминг в фитнес-приложение наш клиент столкнулся с задержкой более 20 секунд на HLS. Тренер выполнял упражнение, а зрители видели его действия с опозданием — это разрушало интерактивность. Мы предложили альтернативу: WebRTC с задержкой 500 мс и HLS для записи. WebRTC обеспечивает задержку в 30 раз меньше HLS. За 4 недели развернули систему, которая выдержала 10 000 одновременных зрителей. Закажите аудит вашего приложения — мы определим оптимальную архитектуру.
Основные технические проблемы
Задержка и буферизация. HLS нарезает поток на сегменты по 6 секунд — итоговая задержка 15–30 с. Для интерактива (голосования, чат) это неприемлемо. LL-HLS уменьшает до 2–5 с, но требует поддержки на сервере и iOS 14+. WebRTC решает проблему кардинально, но сложнее в масштабировании.
Синхронизация аудио/видео. При кодировании на мобильном устройстве важно выставить GOP size и битрейт. В нашем проекте на Android использовали MediaCodec с фиксированным GOP=2 и битрейтом 2 Мбит/с — это дало стабильную картинку даже при падении скорости до 1 Мбит/с.
Масштабирование медиасервера. Один сервер Wowza держит до 1000 подключений. Для 10 000 зрителей пришлось настроить кластер из 4 нод с балансировкой через AWS ALB. Cloudflare Stream снимает эту боль, но дороже.
Как мы это делаем: стек и конфигурации
Начинаем с аудита требований: целевая задержка, ожидаемая аудитория, бюджет. Для MVP выбираем RTMP → HLS. Для продакшена с низкой задержкой — WebRTC + LL-HLS fallback.
iOS стриминг. Базовый стек: Swift 5.9, HaishinKit (RTMP/ SRT/ HLS). Пример конфигурации:
let rtmpStream = RTMPStream(connection: RTMPConnection()) rtmpStream.videoSettings = VideoCodecSettings( videoSize: CGSize(width: 1280, height: 720), bitRate: 2_000_000, frameInterval: 2, frameRate: 30 ) rtmpStream.audioSettings = AudioCodecSettings(bitRate: 128_000) Android стриминг. Streampack или собственный код на CameraX + MediaCodec + RTMP-клиент.
val streamer = CameraStreamer(context, enableAudio = true) streamer.configure( AudioConfig(startBitrate = 128_000, sampleRate = 44100, channelConfig = CHANNEL_IN_STEREO), VideoConfig(startBitrate = 2_000_000, resolution = Size(1280, 720), fps = 30) ) Медиасервер. Используем Wowza Streaming Engine или Ant Media Server. Для WebRTC — Ant Media или Janus.
Как снизить задержку стрима до 500 мс?
Переход на WebRTC — единственный способ получить задержку < 1 с. Ключевые шаги:
- Развернуть сигнальный сервер (например, на Node.js + Socket.io).
- Настроить TURN-сервер (coturn) для пробоя NAT.
- Выбрать медиасервер, поддерживающий WHIP-инжест (Cloudflare Stream, Ant Media 2.x).
- На мобильном клиенте использовать WebRTC.org SDK (Google для Android, native для iOS).
Для массового просмотра (1000+ зрителей) WebRTC перегружает сервер — используйте SFU (Selective Forwarding Unit). Ant Media и Janus поддерживают SFU. Источник: WebRTC
Почему WebRTC не всегда подходит для массовых трансляций?
WebRTC требует постоянного P2P-соединения или SFU. Каждый зритель потребляет около 2 Мбит/с нисходящего трафика. Для 10 000 зрителей нужно 20 Гбит/с — дорого. Альтернатива: транскодировать поток в HLS на сервере и раздавать через CDN. Это увеличивает задержку, но экономит ресурсы. Мы используем гибридную схему: интерактивные сценарии (голосование) через WebRTC для небольшой группы, массовый просмотр — через HLS.
Сравнение протоколов
| Технология | Задержка | Масштабируемость | Сложность | Рекомендация |
|---|---|---|---|---|
| RTMP → HLS | 15–30 с | Высокая | Низкая | Для записей и неинтерактивных трансляций |
| RTMP → LL-HLS | 2–5 с | Высокая | Средняя | Компромисс, если iOS 14+ |
| SRT → HLS | 10–20 с | Высокая | Средняя | Для нестабильных сетей |
| WebRTC (SFU) | < 500 мс | Средняя | Высокая | Для интерактива и малых групп |
| RTMP → RTMP | 1–5 с | Низкая | Низкая | Только для стримеров (один зритель) |
Сравнение медиасерверов
| Сервер | Протоколы | Масштабирование | Стоимость |
|---|---|---|---|
| Wowza | RTMP, HLS, LL-HLS | Кластер до 10 нод | Коммерческая лицензия |
| Ant Media | WebRTC, RTMP, HLS | Встроенный кластер, SFU | Бесплатный (Community) |
| Janus | WebRTC | SFU, шардирование | Open source |
Процесс работы
- Аналитика — замеряем требования к задержке, аудитории, устройству. Определяем протокол и сервер.
- Проектирование — архитектура клиент-сервер, схема потоков, конфигурация медиасервера.
- Реализация — пишем код на Swift/Kotlin/Flutter, настраиваем сервер, тестируем на реальных устройствах.
- Тестирование — нагрузочное (до 10 000 виртуальных зрителей) и сетевое (3G, 4G, Wi-Fi).
- Деплой — CI/CD, мониторинг (Prometheus + Grafana), документация.
Что входит в работу
- Аудит текущего приложения и подбор архитектуры.
- Интеграция стриминга на одной платформе (iOS или Android) с RTMP.
- Развёртывание медиасервера (Wowza или Ant Media).
- Чат на WebSocket/Firebase с базовой модерацией.
- Нагрузочное тестирование и оптимизация.
- Инструкции для разработчиков и админов.
Сроки ориентировочно
- MVP (один протокол, одна платформа, без чата) — 2–3 недели.
- Полноценная система (две платформы, LL-HLS/WebRTC, чат, запись) — 2–3 месяца.
Стоимость рассчитывается индивидуально после аудита. Обращайтесь — назовём точную цифру.
Типичные ошибки
- Использовать HLS для интерактива — задержка убьёт UX.
- Не настраивать GOP — при падении пакетов артефакты.
- Забыть про TURN-сервер для WebRTC — клиенты за NAT не подключатся.
- Экономить на медиасервере — при росте аудитории всё упадёт.
Архитектура для продакшена
Клиент (iOS/Android) → RTMP/WHIP → Ant Media Server → транскодинг в LL-HLS/WebRTC → CDN (Cloudfront) → зрители. Чат: WebSocket server на Go + Redis для масштабирования.Свяжитесь с нами для консультации — подберём оптимальное решение под ваш бюджет и сроки. Гарантируем стабильную работу даже при пиковых нагрузках.