веб связь что такое
Что такое WebRTC?
WebRTC (Web Real Time Communications) — это стандарт, который описывает передачу потоковых аудиоданных, видеоданных и контента между браузерами (без установки плагинов или иных расширений) или другими поддерживающими его приложениями в режиме реального времени. Данная технология позволяет превратить браузер в оконечный терминал видеоконференцсвязи. Чтобы начать общение, достаточно просто открыть веб-страницу конференции.
В этой статье мы раскроем некоторые особенности применения WebRTC, а также рассмотрим преимущества и недостатки данной технологии.
Содержание
Примеры сервисов, использующих WebRTC
TrueConf Server — отечественная ВКС платформа, основанная на современной масштабируемой архитектуре SVC, работает как в локальных сетях, так и через Интернет. Сервер вебинаров разворачивается на оборудовании вашей компании, что гарантирует защиту персональных данных от доступа третьих лиц. Благодаря высокому разрешению видео (до 4К) и инструментам для совместной работы прекрасно подходит для трансляций онлайн-мероприятий, дистанционного образования и удаленной работы.
Google Meet
Google Meet — сервис мгновенного обмена сообщениями, а также проведения видео- и аудиозвонков, выпущенный в 2017 году компанией Google. В браузерах, основанных на Chromium (Google Chrome и др.) используется много скрытых возможностей WebRTC, которые не описаны в документации и периодически появляются первыми в его решениях для Meet (как и в его предшественнике Hangouts). Так было с захватом экрана, размытием фона, поддержкой аппаратного кодирования на некоторых платформах.
Jitsi Meet
Jitsi Meet — приложение с открытым исходным кодом, выпущенное компанией 8×8. Технология Jitsi основана на архитектуре Simulcast, что означает нестабильную работу на слабых каналах связи и высокие требования к скорости подключения на стороне сервера. Позволяет проводить веб-конференции только в браузере и не имеет полноценных клиентских приложений для совместной работы, поддержаны конференции с количеством участников не более 75 (до 35 с высоким качеством связи). Для полноценного использования Jitsi в корпоративной среде необходима самостоятельная разработка и установка дополнительного ПО.
BigBlueButton
BigBlueButton – это свободное программное обеспечение для видеоконференцсвязи. Особый акцент разработчики делают на дистанционном образовании (присутствуют такие функции как интерактивная доска, показ контента, поддержка опросов и т. п.). Поддерживает веб-конференции до 100 участников.
А что насчёт Zoom
Как работает WebRTC
Рассмотрим работу технологии на примере звонка между двумя абонентами через браузер:
Особенности работы WebRTC на мобильных устройствах
Преимущества стандарта
Недостатки стандарта
WebRTC для рынка ВКС
Популярность технологии
На сегодняшний день WebRTC второй по популярности после проприетарного протокола Zoom протокол видеосвязи и опережает все остальные стандартные (H.323 и SIP) и проприетарные (Microsoft Teams и Cisco Webex) протоколы.
Увеличение числа ВКС-терминалов
Технология WebRTC оказала сильное влияние на развитие рынка ВКС. После выхода в свет первых браузеров с поддержкой WebRTC в 2013 году потенциальное количество терминалов видеоконференцсвязи по всему миру сразу увеличилось на 1 млрд. устройств. По сути, каждый браузер стал ВКС терминалом, обладающим базовыми возможностями для участия в видеоконференциях.
Использование в специализированных решениях
Использование различных JavaScript библиотек и API облачных сервисов с поддержкой WebRTC позволяет легко добавить поддержку видеосвязи в любые веб-проекты. Ранее для передачи данных в реальном времени разработчикам приходилось изучать принципы работы протоколов и использовать наработки других компаний, которые чаще всего требовали дополнительного лицензирования, что увеличивало расходы. Уже сейчас WebRTC активно используется для организации видео-контакт-центров, проведения вебинаров и т. п.
Конкуренция с Flash
WebRTC и HTML5 стали смертельным ударом для технологии Flash, которая и так переживала свои далеко не лучшие годы. С 2017 года ведущие браузеры официально перестали поддерживать Flash и технология окончательно исчезла с рынка.
Тонкости работы с технологией WebRTC
Кодеки в WebRTC
Кодеки WebRTC можно разделить на обязательные (браузеры, реализующие данную технологию должны их поддерживать) и дополнительные (не включённые в стандарт, но добавленные некоторыми браузерами).
Аудиокодеки
Для сжатия аудиотрафика в WebRTC используются обязательные кодеки (Opus и G.711) и дополнительные (G.722, iLBC, iSAC).
Opus — это аудиокодек с низкой задержкой кодирования (от 2.5 мс до 60 мс), поддержкой переменного битрейта и высоким уровнем сжатия, что идеально подходит для передачи потокового аудиосигнала в сетях с переменной пропускной способностью. Является основным аудиокодеком для WebRTC. Opus — гибридное решение, сочетающее в себе лучшие характеристики кодеков SILK (компрессия голоса, устранение искажений человеческой речи) и CELT (кодирование аудиоданных). Кодек находится в свободном доступе, разработчикам, которые его используют, не нужно платить отчисления правообладателям. По сравнению с другими аудиокодеками, Opus, несомненно, выигрывает по множеству показателей. По ряду параметров он превосходит довольно популярные кодеки с низким битрейтом, такие, как MP3, Vorbis, AAC LC. Opus восстанавливает наиболее приближенную к оригиналу “картину” звука, чем AMR-WB и Speex.
G.711 — устаревший голосовой кодек с высоким битрейтом (64 kbps), который чаще всего применяется в системах традиционной телефонии. Основным достоинством является минимальная вычислительная нагрузка из-за использования лёгких алгоритмов сжатия. Кодек отличается низким уровнем компрессии голосовых сигналов и не вносит дополнительной задержки звука во время общения между пользователями.
G.711 поддерживается большим количеством устройств. Системы, в которых используется этот кодек, более легкие в применении, чем те, которые основаны на других аудиокодеках (G.723, G.726, G.728 и т.д.). По качеству G.711 получил оценку 4.2 в тестировании MOS (оценка в пределах 4-5 является самой высокой и означает хорошее качество, аналогичное качеству передачи голосового трафика в ISDN и даже выше).
G.722 — является стандартом ITU-T, принят в 1988 году, в настоящее время является бесплатным. Может работать со скоростью 48, 56 и 64 кбит/с, обеспечивая качество звука на уровне G.711. И аналогично G.711 является устаревшим. Поддерживается в Chrome, Safari и Firefox.
iLBC (internet Low Bitrate Codec) — узкополосный речевой кодек с открытым исходным кодом. Доступен в Chrome и Safari. Из-за высокого сжатия потока при использовании данного кодека возрастает нагрузка на процессор.
iSAC (internet Speech Audio Codec) — широкополосный речевой аудиокодек, ранее проприетарный, который в настоящее время является частью проекта WebRTC, тем не менее не обязателен для использования. Поддерживается в Chrome и Safari. В реализации для WebRTC используется адаптивный битрейт от 10 до 52 кбит/с с частотой дискретизации 32 kHz.
Видеокодеки
Вопросы выбора видеокодека для WebRTC заняли у разработчиков несколько лет, в итоге в стандарт вошли VP8 и H.264. Также существуют реализации необязательных видеокодеков (H.265, VP9, AV1).
VP8 — свободный видеокодек с открытой лицензией, отличается высокой скоростью декодирования видеопотока и повышенной устойчивостью к потере кадров. Кодек универсален, его легко внедрить в аппаратные платформы, поэтому очень часто разработчики систем видеоконференцсвязи используют его в своих продуктах. Совместим с браузерами Chrome, Edge, Firefox и Safari (12.1+).
Платный видеокодек H.264 стал известен намного раньше своего собрата. Это кодек с высокой степенью сжатия видеопотока при сохранении высокого качества видео. Широкая распространенность этого кодека среди аппаратных систем видеоконференцсвязи предполагает его использование в стандарте WebRTC. Совместим с браузерами Chrome (52+), Edge, Firefox (в версиях 68+ для Android поддержка была прекращена) и Safari.
VP9 — открытый и бесплатный стандарт сжатия видео, разработанный в 2012 году компанией Google. Является развитием идей, заложенных в VP8 и в последующем был расширен в рамках AV1. Совместим с браузерами Chrome (48+) и Firefox.
H.265 — платный видеокодек, являющийся преемником H.264, обеспечивающий такое же визуальное качество при вдвое меньшем битрейте. Это достигается с помощью более эффективных алгоритмов сжатия. В настоящее время этот кодек конкурирует с бесплатным AV1.
AV1 — открытый кодек для сжатия видео, разработанный специально для передачи видео по сети Интернет. Поддерживается в Chrome (70+) и Firefox (67+).
При указании совместимости кодека с браузером Chrome подразумевается совместимость со всеми Chromium-based браузерами соответствующих версий.
Подключение по WebRTC
В зависимости от конкретной реализации WebRTC возможны отличия в версиях совместимых браузеров. Подробный список поддерживаемых десктопных и мобильных браузеров для TrueConf доступен на странице системных требований.
Если вам интересно узнать, как будет развиваться технология WebRTC, то рекомендуем посетить официальный сайт разработки, а также страницы стандарта проекта и репозитория.
Чем отличается видеоконференция от вебинара?
На первый взгляд видеоконференция и вебинар похожи. Но это не совсем так. Основные отличия между ними рассмотрим в данной статье.
Видеоконференция — это аудио и видеосвязь между людьми, находящимися на расстоянии друг от друга. Эти программы для видеоконференций используют для проведения онлайн-встреч, совещаний, обучения или презентаций продукта. Она обеспечивает двустороннее видео- и аудио общение в режиме реального времени между двумя или более людьми, расположенными в разных местах. Для успешного проведения видеоконференций участники по обе стороны должны иметь компьютер (или мобильное устройство) и интернет.
Вебинар — это особый тип веб-конференции с ограниченным взаимодействием. В вебинаре участвуют спикеры и слушатели, общение здесь «одностороннее». Для взаимодействия между спикером и аудиторией существуют опросы, чат и функция “поднятия руки”.
Дочитайте статью до конца и воспользуйтесь сравнительной таблицей, которая поможет вам лучше понять разницу между вебинаром и видеоконференцией.
Существует ли разница между вебинаром и видеоконференцией?
Хотя и видеоконференция, и вебинар используются для общения и обмена информацией организатора с большим количеством людей по всему миру, все же они отличаются друг от друга.
Основным преимуществом видеоконференций является то, что аудитория находится в постоянном взаимодействии со всеми участниками. Таким образом достигается эффект “живого” общения. Видеоконференции повышают производительность, экономят время, сокращают командировочные расходы и способствуют эффективному сотрудничеству.
В деловом общении личные встречи имеют огромное значение. Особенно, когда вам нужно обсудить финансовую политику, маркетинговые стратегии, контракты. Аудиовизуальное общение в реальном времени всегда наиболее результативно, так как позволяет следить за невербальными сигналами собеседника, понимать ход его мысли и эмоции, которые сопровождают разговор.
Программа для видеоконференций Proficonf позволяет проводить онлайн мероприятия в браузере на высоком уровне в реальном времени. Ведь для запуска конференции необходим лишь компьютер (или мобильное устройство) и интернет-соединение. Функционал записи видеоконференции сохранит все детали вашего мероприятия.
Возможности вебинарных сервисов отличаются от видеоконференций
Его базовые элементы обычно включают:
Для участия в вебинаре нужен ноутбук или мобильное устройство, подключенное к Интернету. Участники вебинара слышат и видят ведущего, демонстрирует и говорит только спикер. Участники могут написать вопросы в чат или воспользоваться функцией поднятия руки.
Все более популярным стало проведение вебинаров на ютуб, фейсбук или вконтакте при помощи прямых трансляций. С помощью платформы Proficonf вы сможете организовать вебинар, пригласить ведущих и транслировать мероприятие в одну из социальных сетей.
В видеоконференции же все участники одинаково активны. В отличии от вебинаров, практически всем в видеоконференции доступен полный функционал комнаты, каждый из участников может быть назначен спикером. Всеобщая активность во многом и является причиной организации именно конференции. Формат проведения видеоконференции все же не исключает возможность образовательного элемента. Как и вебинар, видеоконференцию можно записать.
Сравнение вебинаров и видеоконференций
Таким образом, видеоконференции и вебинары отличаются форматом проведения мероприятия, хоть они и используются для связи с большой аудиторией, расположенной по всему миру. Иногда эти термины используются взаимозаменяемо, но путать их особенности не стоит.
Видеоконференции могут использоваться для двусторонней прямой связи, тогда как вебинар создан главным образом для односторонней связи с ограниченными возможностями взаимодействия.
Веб-сервисы в теории и на практике для начинающих
Что такое веб-сервисы?
Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.
Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.
С другой стороны, если гипотетически разделить Интернет на несколько слоев, мы сможем выделить, как минимум, два концептуальных типа приложений — вычислительные узлы, которые реализуют нетривиальные функции и прикладные веб-ресурсы. При этом вторые, зачастую заинтересованы в услугах первых.
Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки.
Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы.
По сути, веб-сервисы — это реализация абсолютно четких интерфейсов обмена данными между различными приложениями, которые написаны не только на разных языках, но и распределены на разных узлах сети.
Именно с появлением веб-сервисов развилась идея SOA — сервис-ориентированной архитектуры веб-приложений (Service Oriented Architecture).
Протоколы веб-сервисов
На сегодняшний день наибольшее распространение получили следующие протоколы реализации веб-сервисов:
На самом деле, SOAP произошел от XML-RPC и является следующей ступенью его развития. В то время как REST — это концепция, в основе которой лежит скорее архитектурный стиль, нежели новая технология, основанный на теории манипуляции объектами CRUD (Create Read Update Delete) в контексте концепций WWW.
Безусловно, существуют и иные протоколы, но, поскольку они не получили широкого распространения, мы остановимся в этом кратком обзоре на двух основных — SOAP и REST. XML-RPC ввиду того, что является несколько «устаревшим», мы рассматривать подробно не будем.
Нас в первую очередь интересуют вопросы создания новых веб-служб, а не реализация клиентов к существующим (как правило поставщики веб-сервисов поставляют пакеты с функциями API и документацией, посему вопрос построения клиентов к существующим веб-службам менее интересен с точки зрения автора).
SOAP против REST
Проблемы данного противостояния хорошо описаны в статье Леонида Черняка, найденой на портале www.citforum.ru.
По мнению же автора, кратко можно выделить следующее:
SOAP более применим в сложных архитектурах, где взаимодействие с объектами выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки данной теории, вполне применимым может оказаться именно REST ввиду своей простоты и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило — в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы — PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.
В любом случае вам решать, что больше подойдет вашему приложению. Вполне вероятно, вы даже захотите реализовать оба протокола, чтобы оставить выбор за пользователями службы и — это ваше право.
Практическое применение веб-сервисов
Поскольку речь идет о практическом применении, нам нужно выбрать платформу для построения веб-службы и поставить задачу. Так как автору ближе всего PHP 5, мы и выберем его в качестве технологии для построения службы, а в качестве задачи примем следующие требования.
Допустим, нам необходимо создать службу, предоставляющую доступ к информации о курсах валют, которая собирается нашим приложением, и накапливается в базе данных. Далее посредством веб-сервиса, данная информация передается сторонним приложениям для отображения в удобном для них виде.
Как видим задача довольно проста и, с точки зрения самой службы, ограничивается лишь чтением информации, но в практических целях нам этого будет достаточно.
Этап первый — реализация приложения сбора информации о курсах валют.
Информацию о курсах валют мы будем собирать со страниц сайта НБУ (Национального Банка Украины) ежедневно и складывать в базу данных под управлением СУБД MySQL.
Создадим структуру данных.
Таблица валют (currency):
Таблица номиналов обмена (exchange):
Для работы с базой данных воспользуемся ORM слоем на базе пакета PHP Doctrine. Реализуем граббер:
класс Grubber (models/Grabber.php):
и сам граббер (grabber.php):
Теперь заставим наш граббер отрабатывать раз в сутки в 10:00 утра, путем добавления команды запуска граббера в таблицы cron:
Все — у нас есть достаточно полезный сервис.
Теперь реализуем веб-сервис, который позволит другим приложениям извлекать данные из нашей базы.
Реализация SOAP сервиса
Для реализации веб-сервиса на базе SOAP протокола, мы воспользуемся встроенным пакетом в PHP для работы с SOAP.
Поскольку наш веб-сервис будет публичным, хорошим вариантом будет создание WSDL файла, который описывает структуру нашего веб-сервиса.
WSDL (Web Service Definition Language) — представляет из себя XML файл определенного формата. Подробное описание синтаксиса можно найти здесь.
На практике будет удобно воспользоваться функцией автоматической генерации файла, которую предоставляет IDE Zend Studio for Eclipse. Данная функция позволяет генерировать WSDL файл из классов PHP. Поэтому, прежде всего, мы должны написать класс, реализующий функциональность нашего сервиса.
класс CurrencyExchange (models/CurrencyExchange.php):
Отметим, что для автоматической генерации WSDL, нам необходимо написать комментарии в стиле javadoc, потому что именно в них мы прописываем информацию о типах принимаемых аргументов и возвращаемых значений. Неплохо также описывать в нескольких словах работу методов — ведь WSDL послужит описанием API для сторонних разработчиков, которые будут использовать ваш веб-сервис.
Не пишите в докблоках param void или return void — для WSDL это не критично, но вот при реализации REST доступа к тому-же классу у вас возникнут проблемы.
Теперь в Zend Studio входим в меню File->Export. выбираем PHP->WSDL, добавляем наш класс, прописываем URI-адрес нашего сервиса и создаем WSDL-файл. Результат должен быть примерно таким: http://mikhailstadnik.com/ctws/currency.wsdl
Если вы будете добавлять новую функциональность в ваш веб-сервис, вам нужно будет пересоздавать WSDL-файл. Но здесь не так все гладко. Следует учитывать, что SOAP-клиент, который уже запрашивал ваш WSDL файл, кеширует его на своей стороне. Поэтому, если вы замените старое содержимое новым в WSDL файле, некторые клиенты его не прочтут. А значит, при добавлении новой функциональности, дописывайте версию в имя вашего файла. И не забудбте обеспечить обратную совместимость для старых клиентов, особенно если вы не являетесь их поставщиком.
С другой стороны, WSDL довольно жестко задает структуру веб-сервиса, а это значит, что, если существует необходимость ограничить функциональность клиента по сравнению с сервером, вы можете не включать определенные методы ваших классов в WSDL. Таким образом они не смогут быть вызваны, несмотря на то, что существуют.
Реализация же самого сервера не предстваляет теперь никакой сложности:
Вы можете попробовать веб-сервис в работе по адресу: http://mikhailstadnik.com/ctws/
Там же доступен тестовый клиент: http://mikhailstadnik.com/ctws/client.php
Код простейшего клиента может быть таким:
Реализация REST сервиса
REST — это не стандарт и не спецификация, а архитектурный стиль, выстроенный на существующих, хорошо известных и контролируемых консорциумом W3C стандартах, таких, как HTTP, URI (Uniform Resource Identifier), XML и RDF (Resource Description Format). В REST-сервисах акцент сделан на доступ к ресурсам, а не на исполнение удаленных сервисов; в этом их кардинальное отличие от SOAP-сервисов.
И все же удаленный вызов процедур применим и в REST. Он использует методы PUT, GET, POST, DELETE HTTP протокола для манипуляции объектами. Кардинальное отличие его от SOAP в том, что REST остается HTTP-запросом.
Поскольку в PHP пока еще нет реалзации REST, мы воспользуемся Zend Framwork, в который включена реализация как REST клиента, так и REST севера.
Воспользуемся уже готовым классом CurrencyExchange. Напишем сам сервер:
Как видите все очень сходно и просто.
Однако, следует оговорить, что наш REST-сервис менее защищен, чем SOAP-сервис, так как любой добавленый метод в класс CurrencyExchange при его вызове отработает (сам класс определяет сруктуру сервиса).
Проверим работу нашего сервиса. Для этого достаточно передать параметры вызова метода в сроке GET-запроса:
При желании или необходимости вы можете самомтоятельно задавать структуру ваших XML ответов для сервиса REST. В этом случае, также будет необходимо позаботиться и о создании определения типа вашего XML документа (DTD — Document Type Definition). Это будет минимальным описанием API вашего сервиса.
Простейший тестовый клиент к REST сервису может быть в нашем случае таким:
В принципе, Zend_Rest на сегодняшний день нельзя назвать наиболее точной реализацией принципов REST. Утрируя, можно говорить о том, что эта реализация свелась к удаленному вызову процедур (RPC), хотя философия REST гораздо шире.
Вы можете скачать пример в исходных кодах c PHP Doctrine и Zend Framework (4,42 Мб).
Заключение
Мы выполнили задачу минимум и показали, что такое веб-сервисы, для чего они нужны и как их реализовывать. Естественно, приведенный пример, возможно, несколько оторван от жизни, но он был выбран лишь в качестве инструмента для объяснения предмета и сущности веб-сервисов.
Кроме того мы увидели, что реализация веб-сервиса — задача довольно простая при использовании современного инструментария, который позволяет сконцентрироваться, в первую очередь, на разработке функциональности самого сервиса, не заботясь о низкоуровневой реализации протоколов.
Автор надеется, что данный материал будет действительно полезен тем, кто становится на тропу разработки веб-служб.
Видеоконференция
Видеоконференция — это сеанс связи между двумя пользователями или группой пользователей, независимо от их месторасположения. Количество участников, которые выводятся на экран, напрямую зависит от режима конференции и от роли пользователя в текущей конференции.
Выделяют четыре режима видеоконференций:
Видеоконференции — это не только видеосвязь, но и инструменты совместной работы, незаменимые для корпоративных коммуникаций. Отечественная ВКС-платформа TrueConf Server дает пользователям массу возможностей для удаленной работы над проектами:
Что нужно для проведения видеоконференции?
Для обеспечения участников звуком и картинкой используется различное периферийное оборудование: камеры, экраны, микрофоны, спикерфоны, гарнитуры, конгресс-системы и проекторы. В качестве среды передачи данных может использоваться как сеть предприятия, построенная по различным принципам, так и глобальная сеть интернет. Современные видео- и аудио кодеки, специализированные сетевые протоколы, различные алгоритмы обработки сигналов позволяют добиться качественной связи практически на любых каналах связи.
Зачастую во время видеоконференции необходима демонстрация различных медиа данных, для этого системы видеоконференций позволяют захватывать и передавать удалённым участникам презентации, изображение рабочего стола или отдельных его окон, а также различные по форматам документы. Достигается это за счёт использования специального программного обеспечения, дополнительных камер (например, документальных камер), захвата сигнала с видеовыходов ноутбуков, ПК и прочих систем, включая медицинские комплексы.
Виды видеоконференций
Существует два основных типа видеоконференций — персональная и групповая. Персональная видеоконференция подразумевает сеанс видеосвязи, в котором участвует всего два абонента. Под групповыми же видеоконференциями подразумеваются все остальные виды видеоконференций. Различные устоявшиеся правила отображения участников видеоконференции для каждой из сторон называются видами видеоконференций. Предлагаем разобраться в этом вопросе подробнее!
Видеоконференции 1-на-1
Здесь всё просто: участвуют два абонента, оба видят и слышат друг друга одновременно. Сразу оговоримся, что во время любого сеанса видеоконференции могут использоваться различные инструменты для совместной работы, такие, как обмен текстовыми сообщениями, файлами, презентациями и прочими медиа данными.
Симметричные видеоконференции
Они же видеоконференции с постоянным присутствием, от англ. Continuous Presence. Так называют сеанс видеоконференции, в котором участвуют более 2 человек и все участники видят и слышат друг друга одновременно. Естественно, видеоконференция подразумевает полнодуплексное общение. Другими словами, это аналог круглого стола, где у всех равные права. Групповая видеоконференция подходит для встреч, где требуется максимальная вовлеченность каждого участника.
Видеоконференции с активацией по голосу
Название такого режима пошло от английского обозначения Voice Activated Switching (VAS). Эта видеоконференция предполагает следующий формат общения: все участники сеанса слышат и видят на своих экранах только выступающего докладчика, в то время, как он сам видит себя, либо предыдущего оратора. Возможны небольшие вариации данного механизма, но суть остаётся следующей: сервер ВКС отслеживает голосовую активность абонентов и переключает транслируемое всем участникам, изображение, на говорящего. У данного режима есть существенные недостатки, например, ложные срабатывания на шум, кашель или звонок мобильного телефона.
Селекторные видеоконференции
Режим, в котором участники делятся на два вида: докладчики и слушатели, где каждый из слушателей может стать докладчиком (с разрешения организатора конференции). Ведущий такой конференции сам назначает докладчиков и может удалить их с видео-трибуны в любой момент.
Этот режим может так же называться ролевой видеоконференцией. Селекторная видеоконференция используется чаще всего при проведении веб-конференций (вебинаров).
Видеоконференции для дистанционного образования
Cпециальный режим, в котором все участники (ученики) видят и слышат только одного вещающего пользователя (преподавателя), а он видит и слышит всех учеников. Ученики не отвлекаются друг на друга, а преподаватель их контролирует.
Видеотрансляция
Вид видеоконференции, в котором докладчик вещает на широкую аудиторию слушателей, при этом, он не видит и не слышит их. Остальные участники видят и слышат только докладчика. Обратная связь возможна только через текстовый чат. Зачастую, для сглаживания изменения сетевых условий, в ходе трансляции вносится значительная задержка до нескольких секунд между вещающим и слушателями.
Оборудование для видеоконференций
В зависимости от места и способа подключения к сеансу видеоконференции, может потребоваться различное периферийное оборудование.
Видеоконференции в переговорной комнате или конгресс-зале
Чтобы качественно оборудовать переговорную комнату, необходимо соблюсти множество нюансов. Естественно, чем их больше, тем выше стоимость подготовки. В первую очередь, необходимо правильно рассчитать и установить систему звукоусиления, на эту тему на одной из Видео+Конференций был хороший доклад. Если зал небольшой, то будет достаточно установить один или несколько спикерфонов (это специальные устройства, совмещающие в себе один или несколько микрофонов и динамиков, и предназначенные для устранения эхо и шумов).
Далее потребуется PTZ видеокамера, от обычной её отличает возможность поворачиваться, наклоняться вверх и вниз, а также приближать и удалять. Такая камера может как в ручном, так и автоматическом режимах (для этого потребуется спец. оборудование) переключаться между лицами докладчиков и залом. В качестве системы отображение рекомендуется использование двух ЖК экранов большой диагонали: один для видео участников, второй для презентаций и прочего контента.
Ну и не последнее место занимает интерьер помещения: хорошая освещенность, контрастный, но не яркий фон на стенах, шумопоглощающие панели и прочее. Как видно, стоимость оборудования переговорной комнаты в зависимости от выбранного решения видеоконференций, периферийного оборудования и отделки, может отличаться на порядок.
Видеоконференции на рабочем месте
Существует уже множество готовых наборов и комплексов, включающих в себя всё необходимое, но занимающее лишнее место на столе. Поэтому зачастую, а также в целях экономии, в качестве терминала видеоконференции используют обычный рабочий ПК, благо разницы в качестве, при правильном выборе периферии, между ним и специализированными аппаратными системами, нет.
Для подготовки ПК к сеансу видеоконференции потребуется хорошая веб-камера (см. список рекомендуемого нами оборудования), к сожалению, большинство встроенных в моноблоки и ноутбуки камер не пригодны для видеоконференций. Гарнитура (желательно USB-гарнитура) либо портативный спикерфон, подключаемый к ПК через USB интерфейс.
Мобильные видеоконференции
Одно из преимуществ видеоконференций — это их мобильность. Их можно использовать, даже находясь в поездке или на ходу. Устройство, которое может выступать в качестве терминала видеоконференций — смартфон, планшетный компьютер или даже часы. На них достаточно установить специальное приложение. Обо всё остальном уже позаботились производители этих устройств: фронтальная камера, мощный центральный процессор, аппаратная поддержка видеокодеков (которая в том числе нужна и для просмотра фильмов или YouTube), ну а хороший динамик и микрофон — это само собой разумеющееся. Такой способ проведения видеоконференций позволит вам быть всегда на связи со своими коллегами, партнерами по бизнесу, друзьями или родственниками вне зависимости от обстоятельств.
С другой стороны, существует ряд сложностей, связанных с мобильными видеоконференциями, некоторые отрасли ещё предстоит решить, чтобы сделать их по-настоящему удобными и популярными, как на ПК.
Что влияет на качество видеоконференций?
В отличие от привычных нам электронных коммуникаций, таких, как электронная почта или обмен сообщениями, видеоконференции относят к так называемым коммуникациям в реальном времени (от англ. Real Time Communications), которые накладывают более серьёзные требования, как на терминалы видеоконференций, так и на каналы связи, их связывающие.
Все мы привыкли судить о качестве соединения по его скорости, что в контексте видеоконференции будет не совсем верно. Заявленная скорость может быстро изменяться во времени, может снижаться под нагрузкой, может кардинально отличаться от направления передачи. В то время, как всё это критически важно для видеоконференций, где равномерность и предсказуемость потока данных наиболее важны. Системе видеоконференций не сложно подстроить видеопоток под широкий диапазон значений от 64 кб/с до, скажем, 4 Мб/с, в зависимости от вида конференции и качества сигнала участников. Гораздо сложнее в реальном времени адаптировать ширину канала под изменяющиеся условия каждого из участников сеанса связи.
В реальных условиях на первое место при оценке качества видеоконференций выходит тип архитектуры, используемой для организации видеоконференций, и способность этой архитектуры работать в постоянно изменяющихся условиях:
Самым простым решением данной проблемы является жёсткое резервирование, как аппаратных, так и сетевых ресурсов системы видеоконференций. Но при этом, такое решение самое дорогое. К счастью, наука и технологии не стоят на месте, и современные системы видеоконференций могут гарантировать отличное качество связи в любых условиях за счёт применения современных программных архитектур. Давайте остановимся на этом вопросе подробнее.
Типы (архитектуры) систем видеоконференций
Чтобы сгладить технические ограничения со стороны терминалов, обмен данными всегда осуществляется через некоего медиума — сервер ВКС.
Очевидно, эффективность такой системы зависит от:
Именно эти параметры мы имеем в виду, говоря о различных архитектурах системы видеоконференций.
Раньше было принято делить их на программные и аппаратные, но примерно с 2014 года это стало не актуально, поскольку появились и программные, и аппаратные решения с нетипичной для таковых архитектурой. Кроме того, все ведущие производители стараются переложить свою ВКС инфраструктуру на виртуализированные среды чтобы поставлять как программное обеспечение.
Мы разберём четыре архитектуры в порядке появления и улучшения друг друга. Краткое описание различий между ними приведено в таблице.
MCU | SFU | Simulcast | SVC |
---|---|---|---|
Раскладка формируется на стороне терминала | |||
Качество видео в реальном времени адаптируется под возможности терминала | |||
Эффективное использование каналов для сформированной раскладки |
Архитектура видеоконференций на основе микширования (MCU)
Вся обработка данных происходит на стороне сервера. После сбора исходных видеопоток со всех терминалов сервер отдельно для каждого терминала:
Такая архитектура называется микширующей или MCU (от англ. Multipoint Control Unit). Системы на основе MCU требуют большой вычислительной мощности и плохо масштабируются, даже с учётом возможной виртуализации. К тому же стоимость подключения нового абонента в подобной инфраструктурах крайне высока.
Архитектура видеоконференций на основе мультиплексирования (SFU, Switching)
Это классический подход к построению программных систем ВКС, по такому принципу, например, работает Skype. В отличие от MCU, сервер ВКС в данном случае не утруждает себя перекодированием, создает копии входящих потоков и пересылает их другим участникам “как есть”. Выходит, что каждый из терминалов получает сразу несколько видеопотоков в полном качестве, которые он просто не может отобразить одновременно. Терминалу приходится уменьшать разрешение каждого входящего видео от каждого из участников на своей стороне, либо просить уменьшать его перед отправкой, что ухудшает качество видео для всех остальных участников.
Плюс у этой схемы один: инфраструктура не требовательна к ресурсам и даже рядовой ПК может выдержать сотни таких конференций одновременно. Но вот минусов значительно больше: терминалу (обычно это простой ПК) приходится декодировать не один, а сразу несколько потоков, а серверу ВКС требуется в несколько раз большая исходящая ширина канала, чтобы вместить в себя все созданные им копии потоков.
Добавим к этому реальные условия, и получим систему, с трудом “переваривающую” кол-во участников больше, чем 3, и резко ухудшающую качество видео для всех, при присоединении к ней мобильного абонента, не способного “переварить” исходное качество картинки, отправляемое другими абонентами.
Архитектура видеоконференций на основе параллельной передачи (Simulcast)
Simulcast объединяет в себе преимущества MCU и SFU, частично адаптируя сетевую нагрузку под возможности терминалов, но не утруждая сервер обработкой видео.
В этой архитектуре сервер получает от каждого терминала не один, а несколько видеопотоков, копирующих изображение камеры в разном разрешении и качестве для разных полос пропускания. Далее, как и в SFU, каждый терминал получает набор отдельных видеопотоков участников, но качество снижается уже без дополнительного перекодирования, а просто за счёт выбора нужной копии.
Но нагрузка, связанная с одновременной поддержкой нескольких уровней качества видео, от этого никуда не исчезает – она перемещается в самое начало процесса и ложится на ВКС-терминал пользователя.
На практике кодирование терминалом трёх исходящих видеопотоков различного качества требует много ресурсов, а по логике вещей оно и вовсе избыточно – ведь информация (изображение) во всех потоках передаётся одна и та же, просто с разной степенью детализации.
К сожалению, разнообразие сетевых условий гораздо шире, чем три варианта ширины потока, которые использует Simulcast медиасервер, так что в реальных условиях ему редко удаётся эффективно использовать каналы и ресурсы терминалов.
Поэтому Simulcast был быстро отправлен на покой новой архитектурной концепцией, позволяющей варьировать качество видео без создания его явных копий.
Архитектура видеоконференций на основе масштабируемого видеокодирования (SVC)
Данная архитектура совмещает в себе все преимущества микширующего подхода и при этом лишена недостатков систем на основе мультиплексирования. Она дешевая, мгновенно масштабируется и работает на любых платформах. Это стало возможным благодаря развитию технологий обработки сигналов и сжатия данных.
Суть заключается в том, что терминал сжимает свой видеопоток слоями: каждый дополнительный слой повышает разрешение видео, его качество и кол-во кадров в секунду. Если канал между терминалом и сервером ВКС хороший, то терминал отправляет максимально возможное кол-во слоёв. Стоит заметить, что слой — это не отдельный видеопоток меньшего качества, а полноценная разница между ним и предыдущим слоем. Тем самым, SVC поток всего на 15-20% отличается по ширине канала от не SVC-потока, и значительно меньше требуемой суммы полосы пропускания независимых потоков.
Сервер ВКС, получив SVC-поток со слоями, просто отсекает лишние без перекодирования, только лишь за счёт выкидывания из него пакетов с данными по определенным правилам. Тем самым, позволяя на лету создавать индивидуальные наборы видеопотоков (“раскладки” окон) для каждого из участников групповой видеоконференции в зависимости от его реальных условий связи.
Сравнение архитектур
В таблице ниже приведены приблизительные показатели нагрузки на сеть и машины в конференции для четырёх человек.
MCU | SFU | Simulcast | SVC | |
---|---|---|---|---|
Исходящий потоков | 1 | 1 | 3 | 1 |
Входящий потоков | 1 | 3 | 3 | 3 |
Исходящий канал, Мб/с | 1,0 | 1,0 | 1,5 | 1,2 |
Входящий канал, Мб/с | 1,0 | 3,0 | 1,0 | 1,0 |
Нагрузка на ЦП | 20% | 60% | 80% | 30% |
Использование современных протоколов и кодеков
Для организации видеоконференцсвязи между различным программным обеспечением и оборудованием сторонних производителей используются стандартные протоколы передачи данных.
Сжатие и воспроизведение звука и видео во время сеанса конференцсвязи осуществляется посредством использования аудио и видеокодеков.
Выводы
Мы рекомендуем при выборе ВКС системы внимательно ознакомиться с принципами её работы и выбрать ту, которая позволит свести к минимуму расходы на её внедрение, масштабирование и поддержку. TrueConf Server соответствует всем указанным требованиям. Подробнее читайте здесь.