howto_onvif_ru


Спецификация ONVIF - детали реализации


[sticky post]Первая запись
лицо
ran_dom
Выбравшись в отпуск, наконец начинаю вести записи в этом сообществе

План:

Поехали...


WS-Discovery
fall, evil, emotions, angel, heaven
ran_dom
Изначально разработан Микрософт для замены проприетарных и основанных на broadcast протоколах, потом доработан Оазисом. Предназначен для единообразного поиска разнообразных устройств по настраиваемым правилам. Реализован через обмен XML через UDP multicast.
Связывает уникальный идентификатор устройства с переменными величинами вроде IP-адреса. Типичные решаемые задачи:
- найти устройство по его идентификатору
- найти адрес ресурса (Uri) по ip
- найти все устройства в сети определенного типа (например камеры или принтеры)
- найти все устройства в комнате (у устройств должна быть прописана метка комнаты, по которой и будет вестись поиск)
- определить вхождение устройства в сеть (как правило - включение питания) и выход
Замеченные проблемы: неоднозначность работы для устройств с несколькими сетевыми интерфейсами. Оригинальная спека Микрософт требовала рассылки оповещений устройством при его входе и выходе, но молчала о том, нужно ли рассылать такие оповещения на сетевые интерфейсы, которые оставались без изменений. Новая спека от Оазис вносит еще большую неопределенность, позволяя при выходе и входе делать частичные уведомления, что полностью несовместимо с клиентами, работающими по старой спеке.

ONVIF и SOAP
fall, evil, emotions, angel, heaven
ran_dom
ONVIF построен на обмене SOAP сообщениями. Какие библиотеки могут быть полезны?
Если вы пишете встраиваемую систему на чистом C - у вас выбор невелик: взять gSoap или написать костыль самому. И хотя библиотека - тот еще глюкодром (почитайте вопросы программистов по подключению плагинов для https или авторизации пользователя), но по возможностям и переносимости у него нет конкурентов.
Если нужен клиент - есть kSoap. Пробовали, работает.
Пробовали использовать Axis2 - она совсем не подходит для ONVIF. Не умеет работать с сотнями методов и тысячами типов данных.

.Net
Для пишущих управляемый код под Windows это будет естественным решением, но надо иметь в виду следующее:
1 - по умолчанию не создаются тела исключений для ошибок, передаваемых через http 400. Для http 500 создаются. Лечится внедрением в стек протоколов своего компонента вместо стандартного (легко получается из стандартного, пару строчек поменять - нужно только знать каких😊).
2 - не сериализуются переменные после Anydata, она съедает все. В общем виде не лечится никак, для важных частных случаев приходится делать ручной разбор.
3 - может пропускать ситуации с отсутствием в XML обязательной переменной, спокойно вставляя null. Приходится делать ручные проверки.
4 - в ONVIF типичный сценарий работы с конфигурациями требует глубокое копирование, которое в общем виде невозможно в .Net.
5 - протокол WS-Discovery реализован только начиная с .Net 4.0 и способом несовместимым с реализацией большинством камер.

Live555 и все-все-все
fall, evil, emotions, angel, heaven
ran_dom
Для обмена медиаданными с устройством нужна библиотека для работы с rtp/rtcp/rtsp/http протоколами. И в устройствах, и в клиентах популярна библиотека live555.
Библиотека очень популярна и вне видеонаблюдения, например популярный плеер VLC основан на ней и использует ее для проигрывания по сети и трансляций по сети.
С ним есть несколько проблем:
 1 - он не поддерживает, и не будет поддерживать ipv6. Хотя дизайн предусматривает инкапсуляцию работы с сокетами и ip-адресами, реально адреса в большей части кода передаются как целые числа. Наш патч, который это исправляет в клиентской части - около 80 килобайт, наша оценка на исправление серверной части вдвое/втрое выше.
 2 - не поддерживает aspect ratio для jpeg. Корректное исправление требует мелких переделок в разных компонентах.
 3 - не поддерживает высокие разрешения (более 2048 точек по ширине или высоте) для jpeg (расширение ONVIF). Переделка требует заметных изменений.
 4 - работа rtsp уровня в режиме мультикаста, похоже, не совсем совместима со стандартом. Детали мы так и не раскопали, но требуются мелкие правки для совместимости с важными игроками.
 5 - разбор элементов rtsp и http сделан на основе строковых сравнений с учетом регистра и регулярных выражений по шаблонам из примеров в спецификациях. Удивительно что это вообще работает. Видимо, другие разработчики или вдохновляются теми-же источниками, или тестируют совместимость с live555.

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


Появление и развитие ONVIF
лицо
ran_dom

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

К началу 2009 года появились первые устройства и первая версия утилиты тестирования – именно на основе отчета о тестировании декларируется совместимость со спецификацией. В организацию вступило около 60 компаний.

К началу 2010 присоединились уже более сотни компаний, число совместимых продуктов пошло на сотни. Хотя эти продукты были совместимы со спецификацией, и проходили тесты – демонстрации совместной работы на PlugFest иначе как провалами назвать было нельзя. Слишком разнились интерпретации у разных производителей, в инструменте тестирования было менее 60 тестов, а неформальное регулярное кросс-тестирование было неразвито.

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

И только в 2011 году PlugFest’ты показали достаточную для реальных применений совместимость у большого списка компаний. Сказались неформальные контакты, увеличение числа тестов в инструменте тестирования до 300+, и общая зрелость спецификации.

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

Продолжение следует...

Переходим к оглавлению


Проблемы интеграции
лицо
ran_dom

Чтобы собрать живую систему видеонаблюдения требуются:

  • Камеры чтобы фиксировать картинку
  • Рекордеры чтобы её записывать
  • Блоки аналитики чтобы её анализировать
  • Видеостены, джойстики, клавиатуры чтобы управлять камерами
  • Менеджмент система чтобы управляться со всем этим зоопарком

Теперь представьте – производителей камер несколько сотен, рекордеров – сотни, аналитики и менеджмента – десятки. И все в чём-то разные. Каждый свою делянку окучивает. Как выбрать?

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

Далее начинается самое интересное – списки совместимости могут быть неактуальными, могут не содержать достоверной информации об уровне совместимости, и прочее…

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

Переходим к появлению и развитию ONVIF

Переходим к оглавлению


Исторический обзор
лицо
ran_dom

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

Некоторые изменения внесло появление PTZ камер – им требовались сигналы управления. Де-факто стандарт продвигается компанией Pelco.

Следующий шаг сделали гибридные системы: сигнал аналоговых камер оцифровывался и записывался в цифровом компрессированном виде. В цифровом виде он мог передаваться по сети удалённым клиентам. В таких системах аналоговая часть была стандартной и совместимой, а цифровая – основанной на проприетарных протоколах (зачастую – и форматах сжатия) производителя. Производитель всех цифровых компонентов (дигитайзер/компрессор/рекордер, сервер вещаний, клиент администратор, клиент просмотра) был один.

Появление IP камер перенесло дигитайзер и компрессор из сервера в камеру – и поскольку производитель камеры не всегда производил все остальные компоненты потребовалось средство интеграции сигнала с камеры в цифровую систему хранения и управления. Здесь подходы разделились – некоторые производители взяли за основу готовые стандарты (в кодировании: MJPEG или MPEG2/MPEG4, в передаче RTSP), другие продолжили пользоваться своими велосипедами. В последнем был определённый смысл: цифровая  камера не только передает данные, но и требует настройки, те какой-то специфичный для камеры компонент на стороне сервера требуется в любом случае.

В результате производители камер поставляли, а производители серверного ПО интегрировали camera-specific SDK.

Переходим к проблемам интеграции

Переходим к оглавлению


Что такое ONVIF
лицо
ran_dom

Что такое ONVIF, зачем он нужен, как им пользоваться и как для него писать.

Первое – прочитайте запись в английской википедии (в русской копия страницы одного из производителей ONVIF-софта в России, надеюсь вставили не они а какой-то ленивый или глупый доброхот).

Посмотрите официальный сайт.

Если коротко – то это некоммерческая организация, занимающаяся выработкой технический спецификаций в области цифрового (IP) видеонаблюдения (поэтому ранее ONVIF расшифровывался как Open Network Video Interface Forum) и систем контроля доступа. Поставленная цель – стандартизация полученных спецификаций формально или де-факто.

Зачем нужна стандартизация? Почему именно в этой области?

Переходим к историческому обзору

Переходим к оглавлению


?

Log in