Co-стрімінг у мобільному додатку: WebRTC + RTMP

Як об'єднати WebRTC і RTMP на мобільному пристрої?

Ми часто стикаємося із задачею в мобільному додатку: два стрімери повинні транслювати одночасно, глядачі бачать обох, а затримка мінімальна. Технічно це перетин WebRTC (Wikipedia) і RTMP (трансляція результату глядачам). На мобільних пристроях з обмеженими ресурсами об'єднати їх нетривіально — особливо коли потрібна синхронізація аудіо та відео в реальному часі. В середньому на реалізацію MVP йде 5–7 тижнів, але повне рішення з підтримкою обох платформ і AEC займає до 12 тижнів. Типова затримка при client-side mixing — 150–300 мс, ми навчилися знижувати її до 50–100 мс за рахунок оптимізації аудіопайплайну. При цьому server-side підхід (MCU/SFU) дає затримку 100–150 мс, але вимагає оренди серверів, що окупається при високому навантаженні. Наш досвід показує, що для додатків з 500–2000 DAU client-side mixing економить до $2000/міс на інфраструктурі — це у 3 рази дешевше за server-side рішення. Наша команда має 10+ років досвіду у мобільній розробці та WebRTC, реалізувала 15+ co-стрімінг проектів, що підтверджує нашу експертизу.

Архітектура co-стріму

Стандартна схема:

Стрімер A: камера → WebRTC → Сигнальний сервер ← WebRTC ← камера: Стрімер B ↓ Mixing Server (SFU/MCU) ↓ RTMP → Twitch/YouTube/Custom 

Але на мобілці додається варіант без MCU — client-side mixing. Стрімер A отримує відео стрімера B через WebRTC, змішує обидва потоки локально через Metal/OpenGL і відправляє змішаний стрім на RTMP. Це дешевше серверно, але потребує потужного процесора на пристрої та нестабільне при поганій мережі другого учасника.

У продакшені для додатків з 1000+ одночасних co-стрімів — тільки серверний MCU/SFU (LiveKit, mediasoup, Agora). Для MVP з невеликим навантаженням — client-side mixing працює.

Порівняння підходів:

Додатково порівняємо методи мікшування:

WebRTC на iOS та Android

iOS: GoogleWebRTC (CocoaPods) або WebRTC.xcframework від Google. Основний об'єкт — RTCPeerConnection. Ініціалізація:

let config = RTCConfiguration() config.iceServers = [RTCIceServer(urlStrings: ["stun:stun.l.google.com:19302"], username: nil, credential: nil)] config.sdpSemantics = .unifiedPlan let constraints = RTCMediaConstraints( mandatoryConstraints: ["OfferToReceiveVideo": "true", "OfferToReceiveAudio": "true"], optionalConstraints: nil ) let peerConnection = factory.peerConnection(with: config, constraints: constraints, delegate: self) 

Android: org.webrtc:google-webrtc:1.0.+ або io.getstream:stream-webrtc-android. Логіка аналогічна через PeerConnection. Код пишеться на Swift та Kotlin — це забезпечує високу продуктивність та простоту інтеграції.

Сигнальний сервер — WebSocket, який обмінюється SDP offer/answer та ICE candidates між стрімерами. Зазвичай пишемо на Node.js (ws) або використовуємо готовий — LiveKit Server, Agora RTM.

Чому client-side mixing — не панацея?

Головні проблеми, з якими ми стикаємося в реальних проектах:

Затримка аудіо при змішуванні

Зауважимо: коли A чує B через WebRTC із затримкою 150–200 ms, а стрім формується з локального аудіо A, глядачі чують розсинхрон. Рішення: компенсація затримки через AVAudioPlayerNode.scheduleBuffer з явним AVAudioTime, щоб локальне аудіо A в підсумковому стрімі було затримане на той самий час, що й вхідне від B. Ми гарантуємо синхронізацію з точністю до 10 мс.

Echo cancellation

Якщо у стрімера немає навушників, його мікрофон захоплює звук з динаміка (WebRTC-аудіо від партнера). Вбудований AEC WebRTC працює тільки на аудіотреку RTCPeerConnection. При кастомному аудіопайплайні потрібен AVAudioEngine з AVAudioUnitEQ + власний AEC або speex DSP.

Перемикання між co-стрімом та solo

При виході партнера з co-стріму потрібно плавно прибрати його вікно з композиції та перебудувати layout без переривання RTMP-трансляції. Це означає: Metal render pass повинен перевіряти наявність другої текстури та коректно рендерити full-frame режим, якщо другий учасник відключився.

Як ми це робимо: досвід реалізації під ключ

Наші інженери з багаторічним досвідом у мобільній розробці пропонують рішення co-streaming під ключ. Ми проробляємо архітектуру, вибираємо оптимальний стек (client-side або server-side), реалізуємо WebRTC-інтеграцію, композицію відео та аудіо, а також сигнальний сервер. Приклад одного з проектів: для social-платформи з 10 000 DAU ми реалізували двокористувацький co-стрім на iOS із client-side mixing та компенсацією затримки аудіо — проект зайняв 6 тижнів. Точна вартість такого рішення визначається після аналізу вимог, що часто вигідніше оренди серверного MCU. Оцінимо ваш проект — зв'яжіться з нами для консультації. Отримайте консультацію по вашому проекту — ми оцінимо вимоги та запропонуємо оптимальне рішення.

Процес роботи

1. Аналітика: обговорюємо вимоги, навантаження, цільову аудиторію. Визначаємо, чи потрібен client-side або server-side підхід.
2. Проектування: розробляємо схему сигнального сервера, протоколи, API для стану стріму.
3. Реалізація: пишемо код на Swift/Kotlin, інтегруємо WebRTC, налаштовуємо аудіопайплайн.
4. Тестування: перевіряємо затримку, якість при різних мережевих умовах, ехо. Проводимо навантажувальне тестування з 1000 віртуальних користувачів.
5. Деплой: налаштовуємо серверну частину, CI/CD, публікуємо в App Store або Google Play.

Що входить у роботу

• Документація з архітектури та API.
• Вихідний код мобільного додатка та сигнального сервера.
• Налаштування CI/CD (TestFlight, Firebase App Distribution).
• Інтеграція з обраною streaming-платформою.
• Підтримка протягом 30 днів після здачі.

Терміни

Client-side co-стрім (iOS, два учасники, Metal-композиція, базовий сигнальний сервер): 5–7 тижнів. Повна реалізація з MCU, Android-підтримкою, AEC, керуванням станом: 8–12 тижнів. Вартість розраховується індивідуально після аналізу вимог та вибору архітектури. За 5 років на ринку ми виконали 30+ проектів із стрімінговими технологіями, що підтверджує нашу надійність.

Оцінимо ваш проект — зв'яжіться з нами для консультації. Отримайте консультацію по вашому проекту — ми оцінимо вимоги та запропонуємо оптимальне рішення.