Обзор Kurento простым языком для не глубоко-технических людей и бизнеса.

Представьте, к вам пришел программист и сказал: для разработки нужен медиа сервер, и он рекомендует Kurento. Как понять, что это лучший выбор? Информации много, но понять трудно: она слишком техническая.

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

Зачем в WebRTC медиасервер

Kurento — это opensource WebRTC-медиасервер. WebRTC — стандартизированный способ передачи данных между браузерами в режиме реального времени с низкой задержкой без использования сторонних плагинов и расширений. WebRTC — полностью клиентская технология, так зачем нам может понадобиться медиасервер?

Основная причина — нагрузка на клиент при большом количестве участников. Количество соединений между участниками растёт в геометрической прогрессии, при этом ухудшается качество видео и растёт нагрузка на трафик и ресурсы системы. WebRTC вполне можно использовать как обычную P2P коммуникацию между 2-6 пользователями (по нашему опыту). При большем количестве нужен медиасервер. Помимо этого появляются сложности, если нам нужно сохранять запись видео в отдельный файл или как-то обрабатывать его на лету, поскольку вся работа лежит на клиенте.

Краткая история Kurento

Kurento разработали в 2010 году в Мадриде как отдельный opensource проект.

Основной язык программирования, на котором написан Kurento — C++. Он позволяет хорошо оптимизировать потребление ресурсов системы.

У медиасервера больше 2500 звёзд на гитхабе и несколько сотен форков — отдельных ответвлений проекта, поддерживаемых сообществом. Имеет множество встроенных модулей — функций для видеоконференций.

На момент написания статьи — сентябрь 2021 — команда разработки Kurento присоединилась к компании Twilio, а для самого Kurento выходят версии с небольшими исправлениями.

Тип лицензии Kurento — Apache

Kurento выпущен под лицензией Apache. Лицензия Apache даёт полную свободу работы с кодом — надо только указать, какие изменения делаете и изначального автора.

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

С полным текстом можно ознакомиться здесь

Архитектура Kurento: сочетание MCU и SFU

Существует два основных типа архитектуры медиасерверов: MCU и SFU.

MCU (Multipoint Conferencing Unit) — это архитектура, похожая на коллаж видео. У нас есть несколько потоков пользователей, которые составляют одну большую цельную картину с неизменным местоположением каждого элемента. При MCU от каждого участника принимается исходящий видеопоток, затем медиасервер склеивает все потоки в один с фиксированной раскладкой. Таким образом несмотря на то, что в конференции много участников, каждый клиент получает на вход только один поток. Это позволяет сильно сэкономить ресурсы процессора и потребление трафика на стороне клиента, однако сильно увеличивает нагрузку на сам сервер, а также ограничивает возможности кастомизации раскладки видеочата. С MCU мы не можем точно определить, какой именно участник находится на видео. Микширование потоков требует больших вычислительных мощностей, растут затраты на содержание сервера. Такой тип архитектуры подходит в основном для митингов с большим количеством участников (> 40). MCU хороша, если нужно получать видеопотоки на слабых устройствах, например, на телефонах, благодаря процессингу на сервере.

SFU (Selective Forwarding Unit) — это архитектура, набравшая популярность в современных WebRTC решениях, которая даёт возможность клиенту видеоконференции принимать только те видеопотоки, которые нужны ему на текущий момент. SFU больше похожа на мозаику, где элементы нужно собирать самому, но при этом порядок сборки вы определяете сами. При SFU каждый участник также отправляет свой поток на сервер, но при этом остальные потоки приходят по отдельности. Такая архитектура лучше распределяет нагрузку между сервером и клиентом и даёт полный контроль над реализацией интерфейса видеочата. В отличие от MCU, серверу с SFU не приходится декодировать и перекодировать входящие потоки. Это помогает значительно снизить нагрузку на процессор сервера. SFU хорошо подходит для бродкастинга (один ко многим или стриминга одного человека) благодаря возможности динамически масштабировать систему в зависимости от количества потоков. В то же время этот тип сервера требует большей исходящей ширины канала сервера, ведь ему приходится передавать больше потоков клиентам.

Сравним эти два типа на примере видеоконференции из 4 участников.

На клиенте:

На сервере c5 large:

Существуют также гибридные системы, которые используют гибридные архитектуры, что позволяет добиться наилучшего результата в зависимости от текущего количества пользователей и потребностей конкретного клиента. Например, если клиент это слабое мобильное устройство, то он может получать один поток от медиасервера как в MCU. Пользователи браузера же будут получать потоки по отдельности, где возможно реализовать уникальный способ сетки элементов как в SFU. Ещё одним случаем будет взаимодействие с SIP устройствами (в основном IP телефония), где поддерживается только MCU. Некоторые гибриды могут на ходу меняться с SFU на MCU, когда число участников достигает определённого порога.

Kurento — гибкое решение, которое позволяет использовать оба типа. По умолчанию Kurento использует SFU и MCU архитектуры помощью Compositor элемента. Вы можете смешать SFU и MCU для получения гибридного типа. По умолчанию Kurento использует SFU.

Основные модули Kurento

Что такое модули: принципы дизайна Kurento

Kurento включает в себя несколько основных модулей, заточенных под работу не только с WebRTC. В него входит функциональность, работающая с записью видео, компьютерным зрением и AR-фильтрами. Медиасервер Kurento — хороший выбор, если нужно напрямую работать с обычным WebRTC, не используя дополнительных обёрток. Это полезно, если хотите интегрировать видеочат с нативным приложением на Android и iOS. Kurento не включает в себя сигнальный механизм, вы можете сами выбрать то, что вам лучше подходит в зависимости от требований проекта, будь то websockets или что-то другое. Kurento — проект с открытым кодом, что снижает затраты на использование медиасервера.

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

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

Основа дизайна архитектуры Kurento — модульность, где каждый медиа элемент — это программный блок, который выполняет одну конкретную задачу и может взаимодействовать с другими элементами. На жаргоне Kurento разработчики называют это Media Pipeline и Media Elements. Медиа элементы — это просто модули, которые соединяются между собой внутри пайплайна. Топологию пайплайна выбирают сами разработчики, это не обязательно должна быть линейная последовательность элементов.

Ниже — об основных модулях Kurento.

WebRTC видеоконференция

Основа Kurento для видеоконференции — WebRtcEndpoint. С его помощью можно передавать WebRTC-стримы, соединяя их между собой в одном пайплайне. В рамках видеоконференции пайплайн можно представить как одну комнату, которая изолирована от других подобных комнат. WebRtcEndpoint — это пользователь, который хочет транслировать своё или смотреть чужое видео.

Запись видео и аудио

Для записи медиасервер использует RecorderEndpoint. Мы можем соединить WebRTC поток с рекордером, а он запишет результат в файловую систему. После соединения и начала видео просто вызовите метод record у рекордера. При записи можно указать ограничения: например, мы можем записывать только аудио или только видео.

Проигрывание стороннего медиа

В Kurento есть встроенный модуль PlayerEndpoint, позволяющий проигрывать сторонние аудио и видео файлы, а так же RTMP и RTSP стримы. Это значит, что вы можете добавить поток с IP камеры и транслировать его остальным участникам видеоконференции. С помощью плеера можно реализовать проигрывание музыки для пользователей, что хорошо подойдёт для музыкальных платформ, онлайн-тренировок или даже text-to-speech. Благодаря гибкости пайплайна, возможно проигрывать медиа не только всем участникам, а также конкретному пользователю в зависимости от ваших нужд. Сделать это можно, создав новый PlayerEndpoint и подключив его к нужному WebRtcEndpoint с помощью connect метода. Как только нужно воспроизвести медиа файл, вызовите метод play у плеера.

Computer vision и фильтры

Медиасервер позволяет использовать множество фильтров. Например, ZBarFilter используется для распознавания QR кодов, FaceOverlayFilter способен распознавать лицо в видеопотоке и выделять его в реальном времени. А с помощью GStreamerFilter можно создать свой кастомный фильтр. Также, у Kurento есть несколько экспериментальных модулей, в т.ч. и фильтров, которые устанавливаются отдельно. Есть kms-crowddetector, который распознаёт толпу, есть kms-platedetector для определения автомобильного номера транспортного средства.

Нет поддержки мультистриминга с разным разрешением

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

Существует вариант решения с созданием нескольких стримов. Можно запросить видео с разными разрешениями и переключаться между ними в зависимости от потери пакетов. Однако, это решение далеко от оптимального, так как сильно нагружает сервер. Так что будем честны: “хорошего” решения тут нет.

Поддержка кодеков в Kurento

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

Kurento Media Server поддерживает такие кодеки как H.264, так и VP8/9 для видео и OPUS для аудио. Они позволяют достичь высокой степени сжатия видеопотока при сохранении высокого качества. Эти кодеки являются текущими стандартами WebRTC. Поддержки AV1 и H.265 нет. Это новейшие стандарты, позволяющие уменьшить битрейт при одинаковом качестве по сравнению с их старшими собратьями. Медиасервер сам сжимает полученный видеопоток до качества, соответствующего полосе пропускания до клиента в данный момент времени и при необходимости транскодирует поток в нужный для клиента кодек.

API, документация, поддержка Typescript

Взаимодействовать с Kurento API можно c помощью библиотеки kurento-client, а также с помощью различных дополнительных библиотек, например kurento-utils. На официальном сайте Kurento есть развёрнутая документация с описанием работы каждого модуля и примерами использования для Javacript и Java. На сайте есть информация не только по работе самого медиасервера, но также по смежным с WebRTC-темам. Например, по настройке TURN (Traversal Using Relay NAT) сервера, необходимого для обхода ограничения коммуникации пользователей, находящимися за симметричными NAT. TURN протокол позволяет получить IP адрес и порт, необходимые для установки WebRTC-соединения в условиях ограничений NAT. В симметричных NAT есть дополнительная защита от фальсификаций транспортных данных. В симметричной таблице NAT сохраняются еще 2 параметра — IP и порт удаленного узла. Пакеты из внешней сети отбрасываются, т.к. данные источника не совпадают с теми, что записаны в таблице. Клиентская библиотека имеет поддержку типов для Typescript.

Количество участников в видеоконференции

У разработчиков Kurento есть свой бенчмарк для определения максимального количества сессий на одной машине. Хотя изначально он предназначен для OpenVidu, для Kurento он также подходит. Ниже можно увидеть таблицу для разных машин на AWS.

Например, один инстанс AWS c5.large с двумя ядрами ЦПУ и 4 ГБ оперативной памяти может выдержать 4 митинга группового типа с 7 участниками. В каждом таком митинге пользователи показывают и смотрят потоки друг друга (многие ко многим).

OpenVidu — коробочный медиасервер на базе Kurento

На основе Kurento существует фреймворк OpenVidu, который предназначен для более простой разработки, если вам не нужно ничего, кроме простых видеоконференций.

Для общения с фреймворком необязательно использовать сервер, достаточно просто подключить клиентскую библиотеку. У библиотеки существует множество обёрток для всех популярных фронтенд-фреймворков, а также для Android и iOS.

OpenVidu — бесплатное решение, но есть и платная версия, которая предоставляет дополнительные возможности для мониторинга и масштабирования WebRTC платформы. А ещё в будущем планируется Simulcast и SVC и автоматическое переключение на P2P сессии для 1-1 случаев.

Когда использовать низкоуровневый медиасервер, а когда коробочный

Кроме OpenVIdu есть и другие коробочные медиа сервера. Их минус — не все функции в них есть. Вам может прийти идея добавить какой-то функционал в свой продукт позже, а в коробочном продукте такого не предусмотрели.

Как принять решение об использовании:

  • перечислите все функции, которые нужны вам в продукте
  • проверьте, что они все есть в выбранном коробочном продукте
  • если знаете, что позже может понадобиться множество функций, о которых сейчас не знаете — используйте низкоуровневый медиасервер

Выводы: когда подойдёт Kurento?

  • для платформы с групповыми видеоконференциями
  • для интеграции с AR
  • для записи видео
  • для проигрывания медиафайлов для участников конференции
  • для работы с чистым RTP, например, для лайвстрима

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

Зато с Kurento можно воплотить любые функции. С коробочными решениями — частая ситуация, когда заказчик просит сделать что-то еще, а в нем такой функционал не предусмотрен.

  • Технологии