Открытый и бесплатный стандарт для вебинаров

Сможет ли WebRTC пошатнуть позиции Flash в сегменте технологий для вебинаров?

Многие годы в сегменте технологий для вебинаров балом правили сложные, дорогие проприетарные системы таких производителей, как Adobe и Wowza, позволяющие реализовать серверную, а в случае с Adobe — еще и клиентскую части. Несмотря на подробную документацию и богатый набор средств разработчика, эти системы имеют, тем не менее, и ряд внутренних “ограничителей”. Основными барьерами для роста являются их платность и “закрытость”, т. е. разработчик вынужден использовать закрытую платформу, выполняющую всю сигнальную и медийную работу, и некоторое стороннее приложение, которое должно быть запущено на конечном устройстве клиента. До недавнего времени никакой альтернативы Adobe Flash-плагину в качестве клиентской платформы не существовало.

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

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

Одной из таких альтернатив является WebRTC. Эта технология была разработана шведской компанией Global IP Solutions еще десять лет назад и успешно применялась в довольно широком спектре систем видеоконференц-связи (ВКС). В 2010 г. Google приобрела один из лучших медиадвижков того времени и перевела технологию в стандарт, сделав ее доступной для всех.

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

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

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

На сегодняшний день единственным недостатком WebRTC, как и любого начинающего стандарта, является его “сырость”, то есть не исключено, что описанное стандартом поведение в рамках того или иного API может быть различным для разных браузеров. Однако это не следует рассматривать как серьезное препятствие для, например, высокотребовательных корпоративных инсталляций: во-первых, стабильность реализации быстро растет от релиза к релизу, во-вторых, проблема решается с помощью специально написанных плагинов, поддерживающих политику безопасности предприятий и полноценно реализующих стандарт WebRTC.

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

Если все абоненты сети используют браузеры или мобильные приложения, поддерживающие WebRTC-прием/публикацию, вебинар организуется по схеме, представленной на рис. 2. В данном случае трансляция основного видео (видео докладчика) производится без использования так называемого транскодинга. То есть видеопоток не декодируется (происходит обычная депакетизация VP8-кадров из медиапотока докладчика) и не кодируется обратно для каждого слушателя (контент пакетируется в зависимости от текущих настроек для каждого клиента). Здесь мы видим два очевидных преимущества. Во-первых, реализация WebRTC Proxy в данной схеме не представляет сложности, так как доступно описание данного стандарта. Во-вторых, все публикаторы/подписчики используют в качестве клиента браузер, поддерживающий данный стандарт, поэтому все проблемы, если они возникают, решаются быстро. В такой схеме минимальны затраты на машинные мощности, потому что основная нагрузка ложится на сеть.

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

Конечно, многие большие и малые предприятия уже обладают теми или иными ВКС-сервисами, но и тут WebRTC принимает вызов. Как правило, все ВКС-системы до недавнего времени реализовывали технологии SIP в сигнальной и Flash RTMP в медийной частях, передавая видео в формате H264. В данных схемах интеграция сигнальной части проходит вполне безболезненно, ну а медийная часть просто добавляет один двусторонний транскодинг.

Пример вебинара с подключением одного слушателя, использующего Flash-плагин в качестве приложения ВКС, представлен на рис. 3. Как видно из схемы, нагрузка на систему не зависит от числа слушателей, поскольку самый ресурсоемкий процесс (перекодирование видео из VP8 в H264) выполняется один раз — для докладчика. Основные риски, связанные с такой реализацией вебинара, сводятся к непредсказуемости поведения используемых в сервисе H264-клиентов. Единственный способ минимизировать их — стимулировать переход пользователей на платформу WebRTC.

Google Chrome и Firefox на десктопе в полной мере поддерживают этот стандарт. Технология работает и на мобильной версии Google Chrome для Android. Подавляющее большинство мобильных устройств и десктопов уже используют Chrome в качестве браузера по умолчанию, поэтому можно рассчитывать на то, что широкий спектр устройств будет поддерживать и обеспечивать хорошее качество работы сервиса, реализующего вебинары. Сейчас смело можно говорить, что фактическое покрытие пользовательских устройств, поддерживающих WebRTC, превышает 50% рынка. И это далеко не предел. Открытость технологии и наличие стандарта будут стимулировать рост устройств и приложений, по умолчанию предоставляющих стандартный (а значит — простой и удобный!) способ обработки медиаданных и обмена данными по сети. Плюс ко всему совсем недавно один из участников комитета по созданию стандарта WebRTC, компания Cisco Systems, за счет собственных патентных отчислений сделала открытой одну из реализаций кодека H264, тем самым окончательно разрушив все объективные препятствия на пути становления стандарта.

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

Автор статьи — руководитель группы медийной разработки компании Mind.