Спільні трансляції в мобільному застосунку: WebRTC + RTMP

Co-streaming у мобільному застосунку: де ламається трансляція

Co-streaming у мобільному застосунку — це коли кілька пристроїв одночасно віддають відео та звук в один ефір: ведучий і гість, два кореспонденти з різних точок, камера з телефона плюс другий ракурс.

Завдання виглядає простим, поки не починається реальна мережа: у кожного учасника свій канал, своя затримка і свої просідання. Саме на стику цих потоків і ламається одночасна трансляція.

Перший частий збій — розсинхронізація аудіо та відео. Відео йде одним каналом, звук іншим, буфери в них різної глибини, і при просіданні мережі картинка відстає від голосу на секунди.

Глядач бачить рух губ раніше за звук або навпаки — ефір стає нечитабельним, а на записі дефект залишається назавжди.

Другий — обрив з'єднання при зміні мережі. Телефон переходить з Wi-Fi на мобільний інтернет, змінюється адреса, і сесія рветься саме в той момент, коли глядачів найбільше. Без перепідключення та наздоганяючої синхронізації потік доводиться піднімати вручну.

Третій — навантаження на сервер. Коли кожен учасник віддає свій потік окремо, серверна частина перекодовує та роздає їх за кількістю глядачів, і зростання аудиторії множить навантаження. Тут і з'являються просідання якості у всіх одразу.

Ми розбираємо, як це закривається на рівні архітектури: єдина часова шкала для звуку та картинки, стійке перепідключення при зміні мережі та схема роздачі, яка не зростає лінійно від кількості глядачів.

Що дає налагоджений co-streaming: ефект у метриках

Налагоджений co-streaming вимірюється не «працює/не працює», а конкретними метриками, які бачить продуктова команда.

Час підключення до ефіру — від натискання «почати» до першого кадру у глядача — тримаємо в межах 2-3 секунд на нормальній мережі та до 5 секунд на слабкому каналі: це той поріг, після якого глядач не йде, не дочекавшись картинки.

Частка успішних сесій (глядач підключився й додивився без розриву) — ключова метрика: на налагодженій схемі вона виходить на 97-99%, тоді як «сира» інтеграція на реальному трафіку просідає до 80-85% через мобільну мережу.

Стабільність трансляції забезпечується адаптацією під канал: бітрейт і роздільна здатність перебудовуються на льоту, при просіданні мережі картинка деградує плавно (зниження якості), а не рветься чорним екраном.

На слабкому каналі — метро, ліфт, перевантажений Wi-Fi — це різниця між «глядач додивився» і «глядач пішов».

Ми закладаємо буферизацію та відновлення з'єднання так, щоб короткочасний провал мережі не вбивав сесію: перепідключення відбувається непомітно для користувача, без перезапуску ефіру.

Якість картинки на виході — окрема метрика: роздільна здатність і чіткість зберігаються настільки, наскільки дозволяє канал, без «мила» та артефактів стиснення.

Ми вимірюємо це часткою кадрів без втрат і часом відновлення після просідання — обидві метрики потрапляють у моніторинг, а не залишаються на словах.

Підсумок у цифрах: час підключення скорочується в рази проти неоптимізованої схеми, частка успішних сесій зростає на 10-15 процентних пунктів, відмови при слабкій мережі падають кратно.

Ці метрики ми знімаємо на реальних пристроях і реальних каналах, а не в ідеальних умовах стенда — саме тому вони збігаються з тим, що бачить користувач.

Способи організації co-streaming: порівняння підходів

Co-streaming можна зібрати трьома способами, і вибір між ними визначає не «красу» картинки, а поведінку застосунку під навантаженням: скільки глядачів витримає ефір, як швидко ведучий побачить реакцію зали і що станеться, коли один з учасників зайде в метро.

Нижче — порівняння за затримкою, масштабованістю та вартістю підтримки, без прив'язки до конкретного стеку.

Пряме з'єднання дає мінімальну затримку — учасники бачать одне одного майже без паузи, але кожен новий співрозмовник додає канал, і на слабкому мобільному інтернеті картинка починає «сипатися».

Сервер-посередник знімає цю проблему: ведучий віддає один потік, а сервер роздає його глядачам, тому масштабованість упирається в інфраструктуру, а не в телефон.

Гібридна схема бере найкраще з двох: затримка між ведучими залишається низькою, а аудиторія підключається через сервер.

На практиці вибір диктує сценарій. Якщо це спільний стрім двох-трьох блогерів з активним чатом — вистачить прямого з'єднання. Якщо ефір дивиться масова аудиторія і потрібен запис — без сервера-посередника не обійтися.

Ми підбираємо схему під задачу і закладаємо запас: застосунок має переживати перехід між мережами і не розривати ефір при зміні ведучого.

Як ми вибудовуємо co-streaming: етапи роботи

Co-streaming майже ніколи не будується «з нуля»: у замовника вже є застосунок, авторизація, профілі та аналітика, і нова схема має вписатися в цю інфраструктуру, не зламавши поточні релізи.

Тому ми ведемо роботу як інженерний проєкт із фіксованими етапами — від обстеження до передачі регламентів, щоб команда замовника розуміла, що і коли з'явиться в продукті.

1. Обстеження. Дивимося поточний застосунок: платформи, архітектуру, використовувані сервіси авторизації та сповіщень, обмеження за навантаженням. Фіксуємо, скільки одночасних ефірів і глядачів має тримати рішення на старті та із запасом на зростання.
2. Проєктування схеми. Визначаємо, де живе медіасервер, як розподіляються ролі ведучого та глядачів, як влаштовані кімнати трансляції, запис і модерація. На цьому етапі узгоджуємо схему потоків і сценарії відмов — що відбувається при обриві зв'язку у ведучого чи глядача.
3. Налаштування потоків. Розгортаємо приймання та роздачу відео, налаштовуємо адаптивні профілі якості під мобільні мережі, затримку та перемикання між каналами зв'язку. Окремо опрацьовуємо поведінку застосунку при слабкому сигналі та переході між мережами.
4. Інтеграція із застосунком. Вбудовуємо модуль трансляції в наявні екрани, пов'язуємо з авторизацією, профілями, пуш-сповіщеннями та аналітикою. Користувач не повинен помічати шва між старою та новою функціональністю.
5. Тестування. Проганяємо сценарії на реальних пристроях і мережах: масовий вхід глядачів, одночасні ефіри, обриви, слабкий канал, тривалі сесії. Перевіряємо навантаження та поведінку при пікових підключеннях.
6. Передача документації. Віддаємо налаштовану схему, опис конфігурації, регламенти підтримки та інструкції для команди замовника — щоб подальші зміни не вимагали нас як єдиних носіїв знань.

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

Політики доступу та ролі в co-streaming

Co-streaming ламається не на кодеку, а на правах: якщо будь-який учасник кімнати може видати себе за ведучого або підключитися до чужого ефіру, жодна стабільність картинки вже не рятує.

Тому модель доступу проєктуємо до першого рядка коду трансляції — ролі, кімнати та токени описуються як єдина схема, а не добираються патчами за інцидентами.

Ролі фіксуємо на рівні сервісу авторизації, а не в клієнті: ведучий, співведучий, гість і глядач отримують різні набори дозволів на публікацію аудіо та відео, на керування сценою та на модерацію чату.

Клієнт лише відображає те, що дозволено, — підміна ролі в застосунку не дає доступу, бо сервер перевіряє її під час кожного підключення до кімнати.

• Ведучий — публікує потік, відкриває та закриває кімнату, призначає співведучих, видаляє учасників.
• Співведучий — публікує потік і модерує, але не змінює склад кімнати та не закриває ефір.
• Гість — публікує аудіо та відео лише після підтвердження ведучого, без прав на модерацію.
• Глядач — приймає потік, може писати в чат і реагувати, публікація заборонена.
• Спостерігач — доступ до статистики та запису без права входу в ефір, для аналітики та підтримки.

Керування кімнатами будуємо навколо життєвого циклу: кімната створюється під конкретний ефір, живе обмежений час і закривається автоматично при простої.

Це прибирає «висячі» кімнати, до яких можна підключитися за старим посиланням, і спрощує розбір інцидентів — за ідентифікатором кімнати видно, хто і коли до неї входив.

Захист потоків тримається на короткоживучих токенах доступу: кожен видається під конкретну кімнату, роль і строк, перевіряється на вході та при продовженні публікації.

Токен не можна перевикористати в іншій кімнаті або після закінчення строку, а відкликання доступу спрацьовує без перезапуску ефіру — учасника відключає від публікації, не розриваючи трансляцію для решти.

Кейс: як ми усунули розсинхрон у застосунку для спільних ефірів

Замовник прийшов із продуктом для спільних ефірів: два або більше ведучих мовлять із застосунку одночасно, глядачі бачать спільну сцену.

Скарги в підтримку йшли за одним сценарієм — звук одного ведучого відставав від відео іншого, а на слабкій мережі сесія рвалася повністю, хоча достатньо було втратити одного учасника. Додивляльність таких ефірів падала: глядач ішов у перші хвилини, варто було картинці «попливти».

WebRTC ми обрали для інтерактивної частини — там важлива затримка між ведучими, — а роздачу широкій аудиторії повели через RTMP на медіасервер. Розсинхрон виникав на стику: потоки приходили з різними часовими мітками, і мікшер збирав сцену без єдиної опорної шкали.

Ми ввели спільне джерело часу для всіх вхідних потоків і буфер вирівнювання, який гасить мережеві ривки, не накопичуючи затримку. Обриви лікувалися окремо: перепідключення учасника стало локальною операцією — його доріжка перезбирається, а ефір для глядачів продовжується.

Що змінили в архітектурі

Розділили ролі: приймання потоків від ведучих, мікшування сцени та роздача глядачам — незалежні вузли. Падіння або перезапуск одного не валить решту.

Для кожного учасника тримаємо резервний канал: при деградації мережі потік іде запасним маршрутом, глядач бачить перемикання якості, а не розрив. Стан сесії зберігається окремо від медіапотоку — після збою ведучий повертається в той самий ефір, а не створює новий.

Метрики до і після

Окремо скажемо про діагностику: ми додали наскрізні мітки на кожному етапі — від захоплення камери до кадру в глядача. Тепер при скарзі видно, на якій ділянці загубився час, замість перебору гіпотез.

Це те, що перетворює разовий ремонт на керований процес: наступний інцидент розбирається за даними, а не за відчуттями.

Чим co-streaming відрізняється від звичайної трансляції?

Звичайна трансляція — це одне джерело, яке публікує потік на сервер, і скільки б глядачів не підключилося, картинка в усіх одна. Co-streaming перевертає схему: мовників кілька, кожен надсилає свій потік зі свого пристрою, а сервер зводить їх у спільний ефір.

Глядач бачить не одне вікно, а композицію — ведучого, співведучого, гостя, екран телефона — і перемикається між ракурсами без перезапуску плеєра.

Ключова відмінність — у моделі публікації. За одиночного мовлення достатньо однієї висхідної сесії: застосунок захоплює камеру й мікрофон, кодує та віддає потік.

У спільному ефірі таких сесій стільки, скільки учасників, і кожна живе на своєму каналі з непередбачуваною якістю мережі. Завдання застосунку — не просто надіслати свій потік, а прийняти чужі, звести їх в єдину сцену та роздати глядачам в одному контейнері.

Звідси вимоги до кількох пристроїв: у кожного свій бітрейт, своя затримка, свій момент входу та виходу з ефіру.

Синхронізація — те, що відрізняє робочий co-streaming від набору окремих відео. Голос ведучого та реакція гостя мають збігатися в часі, інакше діалог розсипається на відлуння та накладання.

Для цього потоки вирівнюють за спільними мітками часу, а розходження звуку й картинки утримують у межах, які вухо не помічає. Якщо гість увійшов із поганим зв'язком, його доріжку притримують у буфері, а не кидають в ефір із запізненням на секунди.

Вимоги до застосунку зростають відповідно.

Потрібні стійкість до зміни мережі — перехід з Wi-Fi на мобільний зв'язок без розриву, — адаптація бітрейту під кожного учасника окремо, а не під спільний потік, і розмежування ролей: хто мовить, хто лише дивиться, кого можна вивести в ефір за запрошенням.

Одиночна трансляція всього цього не потребує — там нема чого синхронізувати й нема з ким ділити ефір.

Часті технічні сумніви щодо co-streaming

Co-streaming майже завжди впирається не в сам факт трансляції, а в чотири технічні питання: як це працює на різних пристроях, що буде з навантаженням при зростанні кількості учасників, як закрити доступи і що робити при слабкому інтернеті. Нижче — відповіді на ті, що найчастіше виникають на етапі оцінки.

Як застосунок витримає навантаження, якщо глядачів стане в рази більше?

Архітектура будується так, щоб кількість глядачів не впливала на навантаження на телефон ведучого: сигналінг і роздача потоку виносяться на серверну частину, а клієнт лише віддає один вихідний потік.

При зростанні аудиторії додаються вузли роздачі, а не потужність пристрою стримера. Це знімає класичну проблему, коли при 50+ глядачах телефон починає грітися і губити кадри.

Як закриваються доступи та захист трансляції?

Доступ видається через короткоживучі токени, прив'язані до сесії та пристрою: посилання не можна переслати і дивитися з чужого акаунта. Потоки шифруються на всьому шляху, а запис і модерація чату налаштовуються окремими політиками. Для платних ефірів додається перевірка права на перегляд на стороні сервера, а не в застосунку.

Що відбувається при слабкому інтернеті у стримера або глядача?

Канал адаптується за зворотним зв'язком: бітрейт і роздільна здатність знижуються ступенями, при втраті пакетів вмикається повторне надсилання, а при повному обриві сесія відновлюється без перезапуску ефіру.

Глядач на слабкій мережі отримує потік з більшою буферизацією — картинка трохи відстає, але не розсипається. Стример бачить індикатор якості і розуміє, коли варто переключитися на резервний канал.

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

Обговоримо ваше завдання щодо co-streaming

Щоб повернутися з оцінкою та планом робіт, а не із загальними словами, нам потрібна ділова розмова.

Co-streaming рідко буває «просто додати кнопку»: у нього є вимоги щодо затримки, щодо кількості одночасних учасників, щодо того, де живе відео — на власному залізі чи в зовнішнього постачальника. Чим точніше ви опишете поточний застосунок і обмеження, тим предметнішим буде наступний крок.

Що нам важливо зрозуміти на вході, щоб оцінка спиралася на факти, а не на припущення:

• Поточний застосунок: платформи, на чому зібрано, як влаштовані авторизація та робота з медіа — це визначає, чи вбудовуємо ми co-streaming у наявну архітектуру, чи частину переписуємо.
• Сценарій ефіру: скільки ведучих одночасно, скільки глядачів, чи потрібен чат, реакції, модерація та запис трансляції.
• Вимоги до затримки: інтерактивна розмова між ведучими та пасивний перегляд — це різні схеми доставки відео, і вибір впливає на всю конструкцію.
• Якість і мережа: цільові платформи, мобільні та повільні канали, поведінка при просіданні зв'язку — від цього залежить логіка перемикання якості.
• Інфраструктура та доступи: чи є власні медіасервери, CDN, обмеження щодо зберігання та приватності записів.
• Терміни та етапність: що потрібно до першого запуску, а що можна винести в другу чергу без переробки основи.

За підсумками розмови ми повертаємося з оцінкою та планом робіт: етапи, що робимо на кожному, які вимоги закриваємо і де точки перевірки результату.

Опишіть завдання — поточний застосунок, сценарій ефіру та обмеження — і ми повернемося з конкретною пропозицією та наступним кроком.