in

Разработка приложений видеоконференцсвязи: протоколы, архитектура и соображения

Всплеск популярности средств видеосвязи стал катализатором развития телемедицины, развлечений, электронного обучения, фитнеса, электронной коммерции и других бизнесов, связанных с онлайн.

Если вы хотите внедрить в свой продукт видеосвязь в режиме реального времени, интеграция готового к использованию решения будет простым способом. Однако все кардинально изменится, если вы решите разработать индивидуальное решение, ключевой функцией которого является потоковое видео.

Классификация платформ видеосервисов

Все бизнес-кейсы для прямой трансляции можно разделить на три группы технологических решений:

  1. Один ко многим: это такие сервисы, как вещание (например, IPTV), VOD (видео по запросу) и прямая трансляция.
  2. Один на один: видеозвонки один на один, видеочат.
  3. Многие ко многим: групповые звонки, конференции с несколькими хостами.

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

Коммуникационные протоколы реального времени для создания видеосервисов

Ключевым моментом при планировании разработки приложения для потокового видео является выбор протокола связи, который определяет способ передачи данных с одного устройства или системы на другую через Интернет. С точки зрения доставки контента существует три основных подхода, связанных с различными транспортными протоколами:

  • MPEG-DASH / HLS – мультимедийный протокол, используемый для кроссплатформенной передачи видеоконтента в реальном времени или по запросу. Например, его можно использовать для потокового вещания по телевидению.
  • WebRTC – это протокол с низкой задержкой, предназначенный для потоковой передачи видео один к одному. Его также можно использовать в других случаях, когда требуется низкая задержка. Для этого требуется более мощная серверная инфраструктура, чем в первом случае. WebRTC разработан специально для определенных бизнес-случаев, поскольку групповые вызовы, широковещательная трансляция или вызовы один на один имеют существенно различающуюся архитектуру. Однако, если мы говорим о видеозвонках, то разработка приложения WebRTC – это правильный путь.
  • RTMP – протокол обмена сообщениями в реальном времени, который может быть оптимизирован для низкой задержки. У него есть несколько вариантов реализации, но он может воспроизводиться только приложениями (в браузерах, с использованием плагинов). Разбивая потоки на фрагменты, RTMP может эффективно передавать больше информации. В основном он используется для трансляции прямых трансляций на таких платформах, как YouTube.Теперь давайте рассмотрим, для каких типов решений можно использовать эти протоколы.

Шаблоны архитектуры приложений для потокового видео / конференций

Архитектура должна выбираться в соответствии с бизнес-обоснованием и функциональностью, которые вы хотите внедрить в свой продукт. Ниже я опишу характеристики архитектуры для различных бизнес-обоснований.

ПРИЛОЖЕНИЯ ДЛЯ ПРЯМОЙ ТРАНСЛЯЦИИ / ВИДЕО ПО ЗАПРОСУ, ТАКИЕ КАК NETFLIX ИЛИ HULU

Для этой группы проектов требуется использование протокола RTMP. Система должна включать несколько важных компонентов:

  • Сервер потоковой передачи: Этот сервер отвечает за обработку входящих потоков от издателей и их распространение среди зрителей. Часто он включает встроенный транскодер.
  • Транскодер: Транскодер является важной частью потокового сервера, ответственной за перекодирование потока от издателя в широковещательный протокол, используемый для потоковой передачи. Это обеспечивает совместимость и оптимизацию для зрителей.
  • CDN (сеть доставки контента): CDN необходима для кэширования и доставки контента зрителям. Без CDN качество выходных данных может колебаться в зависимости от условий сети, что приводит к непоследовательному взаимодействию пользователей. Правильный выбор CDN обеспечивает доступность и производительность прямой трансляции.
  • Бизнес-логика и сервер выставления счетов: Этот компонент управляет бизнес-аспектами потокового сервиса. Он обрабатывает аутентификацию пользователей, авторизацию, выставление счетов и другую бизнес-логику. Это крайне важно для монетизации и управления пользователями.

Другие элементы системы необязательны и зависят от конкретной функциональности, которую вы хотите реализовать. Типичные приложения для прямой трансляции используют NGINX, Amazon services или NodeMediaServer. Идеальное решение будет зависеть от требований бизнеса. Например, готовые к использованию решения, такие как NodeMediaServer, могут подойти для продуктов, которые не будут использоваться широкой аудиторией. Однако для создания бренда и масштабирования потребуется собрать продукт из разных частей.

ПРИЛОЖЕНИЯ ДЛЯ ВИДЕОЧАТА ОДИН НА ОДИН

Приложения для видеочата один на один – самый простой вариант, если не требуется дополнительная функциональность. Эта функциональность может быть реализована в чат-рулетке, приложениях для знакомств и корпоративных системах. Например, мы внедрили индивидуальные вызовы в корпоративной системе связи.

Если клиенты расположены в одной сети (за исключением 3G), требуются следующие части внутренней инфраструктуры:

  • Сервер сигнализации: этот сервер используется для того, чтобы клиенты знали, кому звонить (адреса).
  • Сервер бизнес-логики: Этот сервер обрабатывает аспекты сервиса, связанные с бизнесом.

К сожалению, такие случаи крайне редки. Поэтому в реальных сценариях необходимы серверы двух дополнительных типов, известные как STUN (утилиты обхода сеанса для NAT) и TURN (обход с использованием ретрансляторов вокруг NAT). Нет необходимости разрабатывать серверы такого типа с нуля, поскольку они уже существуют с лицензиями MIT и могут быть легко развернуты.

Ключевым моментом является то, что для TURN требуется настройка пула UDP для ретрансляции. Кроме того, связь в сотовых сетях не будет работать без TURN, потому что они часто используют симметричный NAT и защиту от фальсификации адресов. В таких секторах, как банковское дело и здравоохранение, защита от подделки адресов также распространена, поэтому необходимо использовать серверы TURN.

ПРИЛОЖЕНИЯ ДЛЯ ВИДЕОКОНФЕРЕНЦСВЯЗИ, ТАКИЕ КАК ZOOM Или GOOGLE MEET

Протокол WebRTC используется для приложений для проведения видеоконференций, таких как Zoom и Google Meet, и существует три типа сетевой организации для групповых вызовов в системах видеоконференцсвязи, которые определяют качество и функциональность групповых вызовов.

Ячеистая сеть – это децентрализованная сеть, в которой устройства взаимосвязаны, образуя ячеистую структуру. В отличие от традиционных сетей с центральным узлом, ячеистые сети обеспечивают прямую связь между устройствами. Эта архитектура предлагает такие преимущества, как масштабируемость, избыточность и самовосстановление, но может не обрабатывать большое количество участников и требует значительной пропускной способности для участников.

MCU, обычно используемый в видеоконференцсвязи, управляет несколькими аудиовизуальными потоками при многоточечных конференц-звонках. Он объединяет аудио- и видеоданные отдельных участников в единый поток, отправляемый всем участникам. Этот централизованный подход основан на MCU для обработки и распространения медиапотоков.

В отличие от этого, SFU является еще одним компонентом систем видеоконференцсвязи. Оно не объединяет и не перераспределяет медиапотоки, а выборочно перенаправляет определенные потоки участникам в зависимости от их потребностей, учитывая состояние сети и возможности устройств. SFU часто используются в децентрализованных или одноранговых системах организации конференций и являются наиболее оптимальным выбором для приложений видеоконференцсвязи.

Однако стоит понимать, что в некоторых случаях, когда видеоконференцсвязь не является ключевой функцией, оправданно выбирать интеграцию готовых инструментов, таких как Zoom. Например, это распространенное решение для платформ телемедицины.

Пять вещей, которые следует учитывать при планировании продукта для видеосвязи

Прежде чем приступить к процессу разработки видеосервиса, вам необходимо провести анализ. Этот анализ позволит вам выяснить конкретные требования и выявить потенциальные проблемы.

Например, если вам необходимо реализовать вещание в формате MPEG-DASH / HLS для совместимости с любым браузером или приложением, а также требуется потоковая передача с низкой задержкой и задержками менее секунды, это может быть недостижимо из-за неправильно выбранных стандартов вещания.

Этап архитектурного проектирования и выбора технологии (технический анализ) имеют решающее значение для успеха проекта. Перед началом работы необходимо тщательно изучить все критерии, не только уточнив требования, но и расставив приоритеты для каждого конкретного клиента или проекта. Это гарантирует выбор наиболее подходящего решения, оптимального с точки зрения соотношения затрат и требований, без упущения чего-то важного.

  1. ФУНКЦИИ И ИНТЕГРАЦИИПонимание того, какая функциональность необходима прямо сейчас и может потребоваться в будущем, позволяет разработать правильное техническое решение. Важно учитывать все ограничения и оценивать потребность в дополнительных услугах, предоставляемых при потоковой передаче видео. Такие сервисы могут включать запись, создание скриншотов, функциональность AR / VR и возможности машинного обучения (размытие фона, распознавание лиц и т.д.).
  2. КОЛИЧЕСТВО УЧАСТНИКОВ ВИДЕОСЕССИИВажными факторами, которые необходимо учитывать на этапе планирования, являются количество участников медиа-сессий, а также источники и приемники видеопотоков. Это влияет на выбор технологий, которые позволят передавать видео удовлетворительного качества для всех пользователей.
  3. ЗАДЕРЖКАПод задержкой я подразумеваю, что для вас означает работа в режиме реального времени. Все службы реального времени имеют некоторую задержку. Например, в онлайн-конференциях или прямой трансляции задержка обычно объясняется такими факторами, как стандарты вещания. Даже в продвинутых реализациях процесс начинается примерно с 10-12 секунд и может длиться до минуты. На практике обратная связь обычно осуществляется через чат, а задержки с ответами часто объясняются физическими задержками, связанными с издателем (несвоевременное прочтение сообщения, несвоевременный ответ и т.д.)
  4. УПРАВЛЕНИЕ ЦИФРОВЫМИ ПРАВАМИ (DRM) И СОБЛЮДЕНИЕ НОРМАТИВНЫХ ТРЕБОВАНИЙDRM необходим, поскольку надежной защиты от взлома не существует, даже если канал передачи полностью защищен. Любые вопросы, связанные с внедрением защиты от взлома, необходимо тщательно оценивать с точки зрения компромисса между временем внедрения и уровнем защиты. Важно учитывать, что время внедрения значительно увеличивается с повышением уровня защиты.Отраслевые требования могут предъявлять дополнительные требования. Например, в здравоохранении соблюдение HIPAA предполагает внедрение специальных мер безопасности и соблюдение руководящих принципов по защите конфиденциальной медицинской информации.
  5. ЗАТРАТЫ НА ИНФРАСТРУКТУРУВидеосервисы требуют постоянных затрат на обслуживание, которые зависят от типа услуги и рабочей нагрузки. Они потребляют значительную вычислительную мощность и пропускную способность, за которые необходимо платить либо поставщикам услуг, либо серверам и пропускной способности.Хотя поставщики услуг могут взимать около 4-5 центов за минуту обслуживания (publisher), теоретически самостоятельное внедрение может снизить затраты примерно до 1 цента за минуту, но это зависит от предоставляемых услуг. Некоторые сервисы имеют нестандартные стратегии выставления счетов, такие как Zoom, где вы платите за хост, а не за время, или услуги с фиксированной оплатой по истечении определенного количества минут, что позволяет выбирать сторонние сервисы для различных бизнес-случаев.

Подведение итогов

Эффективность решений для потоковой передачи видео и проведения конференций зависит от их конкретных характеристик. Выбор правильной архитектуры имеет решающее значение для определения того, насколько хорошо будет работать продукт. Важно тщательно учитывать следующие факторы: желаемые функции и интеграции, количество участников видеосеанса, соблюдение нормативных требований и стоимость инфраструктуры.

What do you think?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

GIPHY App Key not set. Please check settings