Інтеграція прямих трансляцій (Live Streaming) у мобільний додаток
При спробі додати live-стрімінг у фітнес-додаток наш клієнт зіткнувся із затримкою понад 20 секунд на HLS. Тренер виконував вправу, а глядачі бачили його дії із запізненням — це руйнувало інтерактивність. Ми запропонували альтернативу: WebRTC із затримкою 500 мс і HLS для запису. WebRTC забезпечує затримку в 30 разів менше HLS. За 4 тижні розгорнули систему, яка витримала 10 000 одночасних глядачів. Ми маємо 10+ років досвіду в стрімінгу, реалізували 50+ проєктів для клієнтів з усього світу. Гарантуємо стабільну роботу системи та оперативний супровід.
Основні технічні проблеми та типові помилки
Затримка і буферизація. HLS нарізає потік на сегменти по 6 секунд — підсумкова затримка 15–30 с. Для інтерактиву (голосування, чат) це неприйнятно. LL-HLS зменшує до 2–5 с (в 5 разів менше), але вимагає підтримки на сервері та iOS 14+. WebRTC вирішує проблему кардинально, але складніший у масштабуванні. Використовуйте джиттер-буфер для згладжування затримок.
Синхронізація аудіо/відео. При кодуванні на мобільному пристрої важливо виставити GOP size і бітрейт. У нашому проєкті на Android використовували MediaCodec із фіксованим GOP=2 і бітрейтом 2 Мбіт/с — це дало стабільну картинку навіть при падінні швидкості до 1 Мбіт/с. Кодек H.265 забезпечує краще стиснення порівняно з H.264, але потребує потужнішого пристрою.
Масштабування медіасервера. Один сервер Wowza тримає до 1000 підключень. Для 10 000 глядачів довелося налаштувати кластер із 4 нод з балансуванням через AWS ALB. Cloudflare Stream знімає цю біль, але дорожче. SFU-архітектура (Selective Forwarding Unit) дозволяє масштабувати WebRTC, але потребує налаштувань.
Типові помилки: використовувати HLS для інтерактиву, не налаштовувати GOP (при падінні пакетів артефакти), забути про TURN-сервер для WebRTC (клієнти за NAT не підключаться), економити на медіасервері (при зростанні аудиторії все впаде).
Як вибрати протокол: WebRTC чи HLS?
Вибір залежить від цільової затримки та аудиторії. Якщо потрібна інтерактивність (голосування, чат) — обирайте WebRTC. Якщо масовий перегляд з мінімальними витратами — HLS через CDN. Оптимальне рішення — гібридна схема, як описано нижче.
Які помилки найчастіше допускають при інтеграції?
Основні помилки: використання HLS для реального часу, нехтування TURN-сервером, економія на медіасервері, відсутність ABR для HLS. Наш досвід показує, що 80% проблем виникають через неправильний вибір протоколу. Ми гарантуємо уникнення цих помилок завдяки аудиту.
Як ми це робимо: стек і конфігурації
Ми пропонуємо рішення під ключ: від аудиту до деплою. Починаємо з аудиту вимог: цільова затримка, очікувана аудиторія, бюджет. Для 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. Також застосовуємо адаптивний бітрейт (ABR) для HLS та кодек H.265 для кращого стиснення. Гарантуємо сумісність з обраним стеком.
Як досягти затримки 500 мс і коли WebRTC не підходить
Перехід на 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 вимагає постійного 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 с | Висока | Середня | Для нестабільних мереж; SRT краще RTMP при втратах до 30% |
| 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 з базовою модерацією.
- Навантажувальне тестування та оптимізація.
- Інструкції для розробників та адмінів.
- Гарантія на працездатність системи протягом 6 місяців.
Строки та вартість
- MVP (один протокол, одна платформа, без чату) — 2–3 тижні.
- Повноцінна система (дві платформи, LL-HLS/WebRTC, чат, запис) — 2–3 місяці.
Орієнтовна вартість MVP від $3000, повноцінної системи від $10000. Вартість фіксована після аудиту. Ми гарантуємо відсутність прихованих платежів. Оцініть ваш проект: зв'яжіться з нами для безкоштовної консультації — назвемо точну цифру.