[Перевод] Трансляция один-ко-многим: нужен ли медиасервер?
TL; DR — ДА.
Очередная статья нашего израильского коллеги по WebRTC и звонкам между браузерами переведена для Хабра. Мы в Voximplant разрабатываем собственное решение для организации видеоконференций через сервер и можем сказать что да, все именно так. Peer-to-Peer штука хорошая, но работает не во всех случаях. А сделать хорошую видеоконференцию через сервер не так просто, когда к серверу подключается множество разных веб-браузеров и мобильных устройств, каждый со своим подключением к интернет и своей реализацией видеостека. Через некоторое время мы расскажем о внутренностях нашего решения, а сейчас слово передается Цахи Левент-Леви, создателю широко популярного в узких кругах bloggeek.me
Трансляция один-ко-многим: нужен ли медиасервер?
Именно такой вопрос я получил в чате поддержки на этой неделе. Ответ был прост — да.
Но далее я получил вопрос, который не ожидал:
Зачем?
Это застало меня врасплох. Не потому что я не знаю ответ, но потому что я не знаю как ответить достаточно кратко, чтобы это поместилось в чате. Еще я считаю, что это не слишком простой вопрос.
Краткий ответ — это лимит ресурсов плюс факт что мы не контролируем бОльшую часть этих ресурсов.
Верхний предел
Всякий раз, когда мы хотим соединить напрямую два браузера, мы должны использовать peer-to-peer соединение.
В Chrome 65 есть верхний предел для таких соединений, который используется сборщиком мусора. Хром не даст создать более 500 параллельных p2p-соединений.
500 — это много. Если вы рассчитываете на более чем 10 параллельных соединений, то должно быть, вы из тех людей, кто знает, что он делает (и вам не нужен мой блог). Создавать более 50 соединений — плохая идея для любого сценария использования, какой я только могу вспомнить.
Поймите, что ресурсы ограничены. Если что-то бесплатно и встроено в браузер, это не значит, что оно не будет сопряжено с некоторыми затратами и серьезными усилиями с вашей стороны.
Битрейт, Скорости и Потоки
Вероятно, это и есть главная причина, почему вы не можете сделать трансляцию (здесь и далее — «броадкаст». Прим.переводчика) на WebRTC или на другой технологии.
Мы нацелены на сложный случай с использованием WebRTC. Обработка медиаданных это трудно. Обработка в реальном времени — еще труднее.
Предположим, что мы хотим броадкаст с низким VGA разрешением. Мы проверили, что битрейт 500 Кб/с дает хороший результат для этого.
Что будет, если мы хотим передавать наш поток 10 людям?
Трансляция нашего потока на 10 человек потребует исходящего битрейта в 5 Мб/с.
Если у нас ADSL-соединение, то мы имеем исходящий битрейт в районе 1–3 Мб/с, поэтому мы не сможем транслировать поток на 10 человек.
По большей части, мы не можем контролировать, как будет вестись трансляция. Через ADSL? Wi-Fi? Сеть 3G с плохим связью? Как только мы связываемся с броадкастом, мы обязаны делать такие предположения.
И это только для 10 зрителей. А что если нам нужно 100 зрителей? Тысяча? Миллион?
В случае с медиасервером уже мы определяем подключение к сети, какое железо использовать для сервера и т.д. Мы можем каскадировать медиасерверы для масштабирования нашего броадкаста. У нас гораздо больше контроля над ситуацией.
Для трансляции WebRTC-потока требуется медиасервер.
Однородность
Актуальный вопрос для групповых звонков, однако он наиболее релевантен для броадкаста.
Когда мы используем WebRTC для броадкаста, множество решений приходится как раз на медиасервер. Например, если у одного зрителя плохое соединение, это приведет к потере пакетов и медиасервер узнает об этом. Что ему следует делать в этом случае?
Хотя и не существует простого ответа, но есть выбор, что делать:
- попросить броадкастера отправить новый I-frame, который коснется всех зрителей и увеличит использование полосы пропускания в ближайшее время (медиасерверу этого бы не хотелось);
- попросить броадкастера понизить битрейт и качество видео, чтобы нивелировать потерю пакетов — это коснется всех зрителей, а не только одного с плохим соединением;
- игнорировать потерю пакетов, т.е. «пожертвовать» одним зрителем для «всеобщего блага» (остальных зрителей);
- использовать Simulcast или SVC и поместить зрителя на «уровень» ниже с более низким качеством. Это не затронет других зрителей.
Большую часть из этого нельзя сделать в браузере. Для проблемного пользователя браузер будет пытаться использовать тот же поток, что и для остальных зрителей; также браузер не сможет хорошо оценить пропускную способность для большого числа зрителей. Просто потому что браузер спроектирован не для этого.
Вам нужен медиасервер
В большинстве случаев, вам понадобится медиасервер по той или иной причине.
Если вы делаете броадкаст, то медиасервер обязателен. И да, Google не найдет вам такой бесплатный сервис или хотя бы опенсорсное решение, направленное на броадкаст.
Всё это не означает «невозможно» — это лишь знак, что вам придется потрудиться, чтобы достичь цели.
