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

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

Почему доступ к видео становится сложным

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

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

Однако инфраструктура наблюдения имеет другую техническую историю. Камеры, сетевые видеорегистраторы, системы управления видео, портативные терминалы наблюдения, дроны и отраслевые платформы мониторинга могут предоставлять потоки через GB/T28181, RTSP, RTP, RTMP, HLS, SIP или другие интерфейсы. Они также могут использовать видеокодеки, выбранные в первую очередь для эффективности хранения, а не для воспроизведения в браузере.

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

Связанный продукт: Диспетчерская консоль Becke

Где H.265 создает разрыв совместимости

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

Проблема в том, что поддержка воспроизведения H.265 доступна не во всех типичных средах WebRTC и браузеров. Поэтому платформа наблюдения может предоставлять полностью валидный поток H.265, который не может быть непосредственно использован приложением WebRTC, применяемым на диспетчерском пункте.

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

В этой архитектуре сервис транскодирования видео получает исходный поток H.265 и преобразует его в H.264 или другой формат, поддерживаемый целевой средой WebRTC. Затем консоль диспетчера использует преобразованный поток вместо попыток декодировать исходный медиа-поток H.265 напрямую.

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

Практическая архитектура шлюза транскодирования

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

Типовой рабочий процесс можно разделить на пять этапов:

1. Платформа диспетчера запрашивает конкретную камеру, дрон, портативное устройство мониторинга или сторонний видеоресурс.

2. Шлюз получает исходный поток через доступный протокол наблюдения или потоковой передачи.

3. Медиа-сервис проверяет входящий кодек, разрешение, частоту кадров, битрейт и формат потока.

4. При необходимости видео транскодируется или переупаковывается в формат, подходящий для среды WebRTC.

5. Преобразованные медиа доставляются в консоль диспетчера на основе браузера для просмотра в реальном времени.

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

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

Межсетевое взаимодействие протоколов в видеосистемах

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

Распространенные интерфейсы, встречающиеся в средах управления и наблюдения, включают GB/T28181, RTSP, RTP, RTMP, FLV, HLS, SIP и WebRTC. Их назначения не идентичны. Некоторые используются для доступа к устройствам наблюдения и управления ими, некоторые для транспортировки медиа в реальном времени, некоторые для распространения потоков, а другие — для сигнализации сеансов или связи с браузером.

Шлюз, расположенный между этими системами, может принимать поток в одном формате и предоставлять его через другой интерфейс, требуемый платформой диспетчера. Например, к камере наблюдения можно получить доступ через RTSP, в то время как существующая платформа мониторинга может предоставлять ресурсы через GB/T28181. Приложению диспетчера не нужно напрямую использовать эти протоколы, если шлюз преобразует их в путь доставки, совместимый с WebRTC.

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

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

Процесс развертывания для реальных проектов

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

Составить карту существующих видеоисточников

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

Отделить сигнализацию от медиа

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

Нормализовать только при необходимости

Транскодирование потребляет вычислительные ресурсы и может вносить дополнительную задержку обработки. Поэтому практичный шлюз должен избегать ненужного преобразования. Если источник уже использует кодек и медиа-профиль, принятый средой WebRTC, переупаковки или пересылки может быть достаточно. Полное транскодирование следует использовать, когда кодеки или медиа-параметры действительно несовместимы.

Использовать извлечение потоков по требованию

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

Обеспечить простоту рабочего процесса оператора

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

Надежность и качество медиа имеют значение

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

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

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

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

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

Заключительные замечания

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

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

Когда тот же шлюз также поддерживает такие интерфейсы, как GB/T28181, RTSP, RTP, RTMP, FLV, HLS, SIP и WebRTC, он становится практическим уровнем совместимости для более широкой архитектуры конвергентной связи. В результате диспетчерская работа позволяет операторам получать доступ к разнородным видеоресурсам через единый интерфейс, в то время как преобразование кодеков и адаптация протоколов остаются за кадром.

Часто задаваемые вопросы

Следует ли постоянно преобразовывать каждый поток наблюдения до того, как оператор его запросит?

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

Можно ли передавать один и тот же поток камеры нескольким операторам диспетчера?

Да, при условии, что архитектура потоковой передачи предназначена для распределения по схеме «один ко многим». Медиа-сервис может получить источник один раз и распространить обработанные выходные данные нескольким авторизованным зрителям, вместо открытия отдельного восходящего соединения для каждого оператора.

Как следует управлять разрешениями на доступ к видео?

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

Что происходит, когда исходный видеоисточник становится временно недоступным?

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