Возможно ли добиться задержки менее секунды в видеобродкасте? А если стрим ещё и идёт на тысячную аудиторию? Да. Как? Ответим на этот вопрос на примере проекта Worldcast Live. Мы делали его на WebRTC. WCL транслирует концерты в HD-качестве на аудиторию в сотни и тысячи человек.
Зачем понижать задержку в видеотрансляции в прямом эфире?
Задержка (latency) менее секунды в видеоконференции — норма, иначе общаться невозможно. Для односторонней же трансляции на большую аудиторию норма — и 2, и даже 20 секунд. Часто это приемлемо: задержка телевизионного сигнала — тоже около 6 секунд.
Но бывают случаи, когда в бродкасте нужна latency менее секунды, как в видеочате:
- Спортивные события
Вряд ли пользователь будет доволен, когда все соседи заорут: “Гол!”, а на его трансляции мяч где-то на центре поля. А если он ещё и ставки вживую делает?
- Интервью
В век пандемии в онлайн перешло не только общение между друзьями, но и интервью с известными личностями. Сложите задержки интервьюера и интервьюируемого, добавьте миллисекунды, потраченные по дороге к пользователю. Чем больше результат — тем хуже опыт для всех сторон.
- Концерты
Плейер WCL встраивается в разные сайты. Трансляция концерта идет на них одновременно в прямом эфире. Если вы смотрите с другом с разных сайтов, задержка в 20 секунд подпортит впечатление от просмотра. Сегодня организаторы концертов пытаются минимизировать задержку до конечного пользователя. Хоть ему и не так важно, услышит он гитарный рифф моментально или через 2 секунды, общий тренд на уменьшение задержки есть. Чем быстрее, тем лучше :)
А ещё...
Примеры выше комбинируются. В Worldcast Live зрители и исполнители на концерте общаются по видеочату. Значит, и latency должна быть как у видеочата: нужно минимальное время между вопросом и ответом.
Как добиться задержки менее секунды в бродкасте?
Используйте WebRTC
Стандартный пакет WebRTC предлагает среднюю задержку в 500 миллисекунд (полсекунды). На этом можно было бы и закончить: просто сделать видеочат, чтобы все друг к другу подключались — не сложно. Но сложно сделать так, чтобы это все стабильно работало на тысячную аудиторию и добавить кастомизацию потоков для повышения их качества.
Базовый WebRTC — это не HD стриминг. И качество аудио достаточно для разговора, но недостаточно для трансляции музыки. Для сокращения задержки WebRTC может ухудшать качество, пропускать небольшие куски видео и аудио. Чтобы этого избежать, придётся залезть под капот WebRTC, что мы и сделали.
Настройте WebRTC
Для того, чтобы уменьшение задержки не шло вопреки качеству и опыту конечного пользователя, требуется дополнительная разработка. Что делали мы для WCL, которая транслирует HD-концерты на аудиторию в тысячи человек:
- включили многоканальное аудио
Стандартное аудио в WebRTC — моно, это 1 канал. Стерео — 2 канала. На WCL 5 аудиоканалов.
- подняли битрейт
Настройки WebRTC по умолчанию ограничивают скорость передачи видео до 500 кб/с. Для активных действий на экране этого мало: если быстро сменяются яркие цвета и есть ограничение в 500 кб/с — качество видео будет понижаться, чтобы пролезть в ограниченный канал, полезут пиксели. Так себе опыт просмотра концерта. Поэтому мы подняли битрейт (пропускную способность) до 1,5 Гб, чтобы передавать HD-видео
- подняли частоту дискретизации
Таким образом мы подняли качество аудио и видеопотоков, низкие и высокие частоты, которые не теряются при кодировании. Что конкретно мы сделали, раскрывать здесь не будем, но если интересно — напишите нам!
Масштабируйте Kurento
Kurento Media Server — WebRTC-сервер с открытым исходным кодом. Для видеостриминга, настройте Master Kurento, через который идёт трансляция. К одному Master Kurento можно подключить до 500 человек, откуда они напрямую забирают видеопоток. Если зрителей больше, в игру вступает Edge Kurento — ответвление от Master, к которому подключаются другие пользователи. Чем больше зрителей на стриме, тем больше Edge Kurento нужно задействовать. Всё вместе это образует схему типа дерева.
В каких случаях оставить задержку больше секунды?
В условиях ограниченного бюджета. WebRTC дороже HLS, если вам нужно масштабирование. Сервер WebRTC на WCL стоит $0,17 в час, что выливается в $122,40 в месяц, если взять 30 дней.
HLS, однако, стоит $0,23 в час, и его, в отличие от WebRTC, можно включать и выключать, избавляясь от необходимости платить за часы простоя. Если взять, что у нас 3 часовых концерта в неделю, то за 12 концертов в месяц мы отдадим чуть меньше, чем $0,28. Разница заметна :) Учтите, что провайдеров серверов много, и цены везде отличаются, но на примере нашего проекта масштаб понятен.
Первая стабильная версия оптимальной задержки для WCL заняла 3,5 недели работы. Если необходимости в latency менее 1 секунды нет — у вас не интервью во время концерта — стоит ли тратиться?
А если вкратце?
Задержка не более секунды в видеобродкасте необходима, если идет общение между участниками или просмотр мероприятия, где что-то стремительно меняется. C WebRTC это возможно даже на тысячи человек, если с технологией поработать.
Если ваше приложение ориентировано на что-то из этого — обязательно приглядитесь к WebRTC. Ну и свяжитесь с нами — поможем.
Комментарии