Материал познакомит с особенностями реализации, преимуществами и основными сферами применения WebRTC в системах видеонаблюдения.
Аббревиатура WebRTC означает Web Real Time Communication, т.е. «веб-коммуникация в реальном времени». Компания Google инвестировала значительные ресурсы в этот стандарт, который был официально анонсирован в мае 2011 года. Спецификация WebRTC с тех пор подвергалась изменениям и дополнениям, проект имеет открытый исходный код и поддерживается Apple, Google, Microsoft, Mozilla и разработчиками. В итоге на данный момент мы имеем вполне законченный открытый web-стандарт, который полностью применим для видеонаблюдения и доступен в виде обычных API-интерфейсов JavaScript во всех основных браузерах (по данным https://webrtc.org).
Почему это так важно? В видеонаблюдении широко распространено использование «толстых клиентов», с помощью которых давно решены все вопросы, связанные с подходами к организации сетей связи и разработкой или применением стандартов обмена информации между сервером и клиентом. Тем не менее, применение «толстого клиента» на оборудовании пользователей может быть невозможным, может накладывать определенные ограничения и даже быть нежелательным по мнению самих пользователей, особенно если приложение необходимо запускать на их оборудовании. Это стало достаточно заметно благодаря общемировой тенденции к организации удаленной работы пользователей с конца 2019 года, т.е. в постковидную эпоху.
В то же время, web-технологии активно применяются практически во всем программном обеспечении, которое мы используем в обиходе, они все чаще используются для интеграции с другими системами при построении комплексных решений, а построение распределенных систем априори подразумевает передачу данных через Интернет.
Хорошей иллюстрацией до сих пор существующей проблемы использования web-технологий в видеонаблюдении является самый базовый элемент систем видеонаблюдения — IP-камеры. IP-камеры передают видео с использованием стандарта RTSP, и этот видеопоток нужно как-то воспроизвести в браузере для того, чтобы эти камеры изначально настроить — например, посмотреть видео, увеличить оптический зум с помощью веб-интерфейса камеры, настроить видеодетекторы на борту видеокамеры и т.д. Для решения этих задач производителями видеокамер часто применяются дополнительные плагины для браузеров, которые необходимо установить, например, довольно часто используется ActiveX со всеми его ограничениями.
Благодаря же возможностям WebRTC в части видеотрансляции в мобильные клиенты и браузеры мы наконец получаем решение, которое должно решить этот вопрос для всех платформ и браузеров и избавить нас от необходимости использования дополнительных плагинов и «толстых клиентов».
WebRTC создавался, чтобы осуществлять видеозвонки через Интернет, обеспечивая при этом эффективное использование сетевой инфраструктуры и экономию трафика. Именно поэтому он вобрал в себя большое количество решений из VoIP-технологий. Некоторые из них:
- обеспечение коммуникации с учётом современного построения сетей связи, а именно — обеспечение установки связи через NAT, когда ни один из участников связи не находится в Интернет с прямым IP-адресом;
- минимальная задержка связи, крайне важная для видеоконференцсвязи;
- удобство и простота использования API.
Для начала разберём первый главный пункт, который интересен с точки зрения видеонаблюдения. Как это выглядит на диаграмме:
Если заменить «Браузер 1» видеосервером, то можно заметить, что это выглядит в точности как один из способов и случаев развёртывания системы видеонаблюдения. Для наглядности добавим ещё камеры и сетевое оборудование:
Нужно пояснить, что STUN сервер на диаграмме — это условное специальное приложение, расположенное в Интернет с IP-адресом. STUN (Session Traversal Utilities for NAT) сервер обеспечивает настройку таблиц маршрутизации NAT в обоих маршрутизаторах, а также позволяет им опосредованно обмениваться информацией друг о друге и о том, что им нужно. Вся дальнейшая видеотрансляция, как можно понять, производится напрямую. В результате стоимость содержания подобного центрального сервиса в Интернет не будет высокой, так как не требуются большие вычислительные мощности, специальные отказоустойчивые хранилища или широкая полоса пропускания данных для входящего и исходящего трафика в дата-центре.
В общем случае STUN-cервер может быть как отдельными сервисом в Интернет, так и единым сервисом с видесервером, в зависимости от архитектуры выбранного решения. Viinex содержит готовый STUN-сервер, что в свою очередь дает следующие преимущества:
- Мы развиваем и поддерживаем законченный набор программного обеспечения, необходимого для развёртывания системы видеонаблюдения с применением WebRTC.
- Сама коммуникация упрощается, так как данные проходят через единое приложение с одним и тем же IP-адресом и портом, что ускоряет скорость установки связи, а в некоторых случаях даже позволяет её установить, когда раздельные STUN- и сигнальные серверы с этой задачей бы не справились.
Видеостриминг в реальном времени
Перейдём ко второму главному пункту — низкая задержка при передаче видео. Сама по себе задержка в доставке информации на экран возникает по очень большому числу причин. Тут и формат данных, и обработка информации, её приём и декодирование данных, а в случае с WebRTC еще и расшифровка. Чем меньше и проще все эти шаги на всех этапах, тем быстрее мы увидим на экране изображение.
Первый шаг мы уже описали — он обеспечивает прямую коммуникацию клиентов, и маршрутизаторы по факту обмениваются друг с другом видеопотоками напрямую. Это, безусловно, сокращает задержку.
Второй шаг — использование в качестве основы транспортного протокола UDP, который не требует квитирования, что означает исключение дополнительного обмена пакетами по доставке. Надо отметить, что настройка таблиц маршрутизации в реальном времени и дальнейшая трансляция возможна при использовании протокола UDP и исходит из основ построения сетей связи для широкополосного Интернет-вещания. Это стандартная технология, которая поддерживается практически всеми маршрутизаторами на рынке, начиная с SOHO-оборудования и заканчивая профессиональными решениями. Для обеспечения качественной доставки пакетов данных при этом используется технология QoS.
Третьим условным шагом в сокращении задержки связи будет то, как передаётся и принимается информация, что тоже может внести свою лепту. Для того, чтобы это продемонстрировать, вернемся к предыдущему материалу о поддержке протокола HLS в Viinex. Как видно из упрощённой диаграммы последовательностей, при передаче данных по протоколу HLS, чтобы начать проигрывание видео, нужно сформировать и передать, следуя соглашению, отрезок видеозаписи клиенту. Время на передачу данных в основном можно сложить из трёх составляющих: время на подготовку (a), время на его трансляцию (b) и время на его полное декодирование и подготовку к проигрыванию (c). Предположим, что наше соглашение — это 10-секундные отрезки записи. Итак, что мы получаем: нам нужно 10 секунд, чтобы накопить нужные данные на стороне отправителя, далее, скажем, 500 мс, чтобы отправить, и 500 мс, чтобы декодировать. Итого a + b +c = 11 секунд. Конечно, можно изменить соглашение на 5-секундное, но нужно понимать, что существуют также подводные камни как при подготовке каждого файла, так и при его подготовке к беспрерывному проигрыванию на стороне клиента.
В WebRTC ничего этого нет, как нет и списка проигрывания отрезков. Передача ведётся в реальном времени без остановки на подготовку каждого отдельного отрезка в определенном формате. В итоге мы практически полностью устраняем число (a) из формулы, в свою очедеь (b) и (с) всегда будут минимальными, так как объём условной передаваемой единицы информации небольшой. Итого получаем в реальной практике при стриминге видео от обычной USB-камеры b+c=230 мс, для отображения видео IP-видеокамеры в браузере мы получили 300…400 мс (т.к. самой IP-видеокамере необходимо время на кодирование видео на борту). Для примера, VLC (стандартные настройки) при получении потока по RTSP тратит на это более секунды.
Почему всё это важно в системе видеонаблюдения — очевидно. Это и быстрая доставка инцидента с видеоизображением сотруднику службы безопасности, что обеспечивает видеоверификацию в реальном времени; это и возможность PTZ-управления в ручном режиме, позволяющая быстро и удобно повернуть камеру в сторону нужного объекта на охраняемой или контролируемой территории.
Оптимизация WebRTC соединения в Viinex
Впрочем, важна не только скорость доставки видеоизображения, но и отзывчивость системы в целом при передаче различных команд.
Посмотрим на диаграмму ниже:
Эта диаграмма здесь не столько для того, чтобы разъяснить все детали процесса, сколько для того, чтобы показать, что довольно много коммуникации происходит на этапе так называемого «рукопожатия», т.е. в процессе установки связи. Лишь последняя нижняя стрелка означает, наконец, передачу видеопотока, а всё что до этого — подготовка. То, что мы оптимизировали в Viinex для использования в системах видеонаблюдения — это сокращение количества таких «рукопожатий», или, другими словами, использование уже установленных соединений, которые, как известно любому специалисту по сетям, вещь достаточно дорогая. После того, как мы установили связь единожды, пользователю в какой-то момент может понадобится сменить видеопоток на экране. В нашем API есть простая команда по смене потока, которая в случае WebRTC просто заменяет уже существующий видеопоток в текущей сессии на новый, т.е. пользователю не нужно ждать, когда установится соединение и через какое-то время на экране появится изображение с запрошенной им камеры. Таким образом мы достигаем существенного повышения отзывчивости при подаче команды на смену видеопотока из-за отсутствия необходимости инициализации нового соединения.
Надо напомнить, что Viinex — это не только передача онлайн-потоков, но и видеозапись. Когда мы просматриваем видеоархив, команды позиционирования во времени записи, пауза, воспроизведение и другие команды тоже выполняются в рамках уже существующей сессии.
Безопасность передачи видео
Немаловажный момент — защита от атак типа MitM (Man-in-the-Middle). Сам перехват данных возможен, но его расшифровка не будет тривиальной задачей. Иначе говоря, понять, что есть в битах, которые вы передаёте, практически невозможно. Для указания ключей шифрования в WebRTC используется стандарт DTLS, а медиа уже передается по SRTP. Шифрование в WebRTC не только обеспечивает секретность передаваемой информации, но и улучшает качество связи, так как вместе с шифрованием приходят контрольные суммы, которые предоставляют возможность определять повреждённые участки данных и не декодировать их. Точнее сказать, это просто невозможно, так как на основании неверной контрольной суммы или самого участка данных потока расшифровать данные нельзя. Эти данные просто отбрасывают.
Другой вид атак — это подмена данных. Viinex поддерживает возможность использования собственных сертификатов. Всё что остаётся — проверять их на стороне клиента, используя контрольные суммы. Таким образом, клиент всегда будет знать, что приходящие данные — не поддельные.
Стандартизация и распространённость
Насколько готовы браузеры сегодня к WebRTC? Тут нужно обратиться к caniuse.com, информация там достаточно постоянно обновляется.
Сейчас она выглядит вполне прилично: WebRTC caniuse.com
Поддержка аппаратного ускорения браузерами
Для любой системы видеонаблюдения очень важно иметь возможность одновременно демонстрировать несколько видеопотоков на экране. Поэтому браузер должен поддерживать аппаратное декодирование за счет использования графического процессора (GPU), чтобы увеличить количество одновременно отображаемых браузером видеопотоков. Спецификация WebRTC на данный момент заявляет лишь о двух кодеках: H.264 и VP9. Последний в видеонаблюдении исторически не используется. В части H.264 всё замечательно: H.264 caniuse.com. Что касается H.265, то ни стандарт WebRTC, ни абсолютное большинство браузеров на дату написания статьи не поддерживают H.265.Сравните, например: H.265 caniuse.com. Поддержка кодека H.265 в настоящий момент наиболее распространена в «толстых клиентах», а не в браузерах.
Проверить, есть ли у вашего браузера поддержка аппаратного декодирования, очень просто. Например, в самом популярном браузере Chrome наберите chrome://gpu.
WebRTC трансляция в реальном времени и трансляция видеоархива
Перейдём к теме трансляции видео. Как можно догадаться, стандарту WebRTC совершенно всё равно — архивное видео передаётся или «живое». Он их не различает. Все команды на проигрывание нужной части архивных записей передаются через API Viinex. Viinex позволяет работать не только с камерами, но и с другими видеоисточниками, например, со сторонними системами охранного видеонаблюдения, фактически реализуя программный шлюз к VMS.
Дополним схему этими решениями, чтобы было нагляднее:
В middleware Viinex сигнатура внешних команд не отличается при работе с архивами записей самого Viinex или записями других систем видеонаблюдения. Преимущество здесь не только в том, что можно работать с онлайн видео или видеоархивом, но и в том, что Viinex поддерживает одновременную работу с сразу с несколькими системами видеонаблюдения, объединяя существующие решения на объекте и предоставляя возможность работать с помощью единого HTTP REST API. Это значительно упрощает работу нашим партнерам, которые разрабатывают системы диспетчеризации и PSIM, потому что они получают возможность работать по единому API с несколькими системами видеонаблюдения одновременно.
Функциональность ретрансляции видеоархива VMS по WebRTC позволяет нашим партнерам, которые хотят предоставить своим заказчикам доступ к видео этих VMS через web, передавать видео в HTML5-совместимом формате. Причем ретрансляция видеоархива по WebRTC от сторонних VMS, которые сами такой функциональности не имеют — это единственный способ. Например, по протоколу HLS, который более предназначен для трансляции видеоархива, наладить взаимодействие со сторонними видеоархивами достаточно сложно, т.к. VMS обычно отдают архив последовательным видеопотоком по RTSP, а не блоками видеоданных, которые нужно готовить на стороне видеосервера. Соответственно, когда видеопоток идет последовательно, нельзя заранее узнать, как этот видеопоток разбить на фрагменты и определить, где же ключевые кадры, с которых должны начинаться эти фрагменты. В этом случае теряется эффективность HLS протокола, когда можно встать на любую точку в видеоархиве и сразу транслировать поток, как это позволяет сделать видеосервер Viineх.
Доступ к системе видеонаблюдения из Интернет с помощью middleware Viinex
Вопрос, на который ответит эта резюмирующая часть материала — как быстро организовать такую «облачную» функциональность при работе с видео в своем собственном приложении, когда вашим пользователям нужно просто предоставить возможность посмотреть живое видео или видеоархив на серверах, установленных у этих пользователей.
Сразу нужно оговориться, что несмотря на применение слова “облачный”, скорее всего в этом тексте мы будем далеки от реального смысла этого слова, т.к. хотим рассказать про конкретный и достаточно распространенный сценарий по доступу в Интернет к ресурсам системы видеонаблюдения, когда видеоданные хранятся непосредственно у пользователя, а основной трафик идет от клиента пользователя к серверу пользователя напрямую, минуя дата-центр, чтобы минимизировать стоимость решения.
Можно видеть, что в нашем случае система видеонаблюдения находится за маршрутизатором, прямого доступа к ней нет, даже единого порта не открыто. Серверы остаются там, где они стояли, в надёжно охраняемом пользователем помещении. Всё открывается и доступно, только когда кто-либо за маршрутизатором этого хочет. Снаружи этим управлять невозможно. Это и безопасность, и простота одновременно. А как известно, простое лучше всего и работает. Не требуется размещения и перемещения каких-либо частей системы видеонаблюдения в Интернет, трафик движется как обычно — от камеры в видеоархивы в локальной сети. Дополнительные сервисы интегрирующего приложения, размещённые в Интернет, в связи с таким “дооснащением”, потребляют минимальный объём трафика и не прогоняют через себя какие-либо видеопотоки. В процессе работы, если нужен какой-либо поток, то он движется напрямую от маршрутизатора пользователя к маршрутизатору системы видеонаблюдения и не проходит через дата-центр.
Решение позволяет работать с системой видеонаблюдения даже в условиях отсутствия у мобильного клиента (компьютера, не имеющего постоянной дислокации) выделенного IP-адреса, игнорируя устройство сетевой инфраструктуры, через которую мы осуществляем доступ в Интернет. Потоковое вещание устроено так, что именно источник информации (а в нашем случае это система видеонаблюдения) отправляет данные. Благодаря стандарту WebRTC, пользователь увидит видеоизображение на экране своего ноутбука, планшета или даже мобильного телефона.
- Первое, чему нужно уделить внимание — это то, что Viinex cодержит собственный STUN сервер, пользуясь терминологией WebRTC. В нашем случае это действительно единый компонент, который дополнительно упрощает процесс установки связи и инфраструктуру решения. STUN сервер Viinex размещается в Интернет и отвечает за первые и все последующие шаги установки связи между клиентом и системой видеонаблюдения. По завершении этой задачи сервер позволяет поддерживать связь, и в случае каких-либо изменений в канале связи (как ни странно, это может произойти не только с клиентом, но и с системой видеонаблюдения) через этот сервер клиент и система видеонаблюдения обменяются новыми данными о своих сетях, и трансляция продолжится. Известно, что в Интернет есть сторонние сервисы или их бесплатные аналоги с открытым исходным кодом, которые можно скачать и установить самостоятельно, но все эти решения не всегда попадают в рамки коммерческого предложения. Для нас важно ещё раз подчеркнуть, что STUN сервер является частью нашего middleware Viinex, и мы будем постоянно его совершенствовать.
- Второе — это собственно видеосервер Viinex. Для разработки вашего решения он выполняет все необходимые задачи в части видеонаблюдения и трансляции видеопотоков по стандарту WebRTC, а также по другим популярным стандартам, таким как RTSP и HLS.
- Третье — видеосервер может работать в режиме “proxy” для других, например, уже установленных на объекте систем видеонаблюдения и представлять их как WebRTC-сервис при работе не только с онлайн видео, но и с архивом.
Тем или иным способом ваше приложение будет готово к решению такой «облачной» задачи. Можно лишь ещё раз перечислить преимущества такого решения:
- Видеонаблюдение работает практически в любом браузере. WebRTC сейчас поддерживается абсолютным большинством браузеров, а том числе популярными Safari, Firefox и Chrome.
- Видеопоток зашифрован по протоколу SRTP.
- Не требуется для развёртываемой инфраструктуры большой пропускной способности каналов связи в дата-центре.
- Полностью сохраняется имеющаяся инфраструктура системы видеонаблюдения. Как итог, фактически создание облачной системы видеонаблюдения на базе уже существующей.