onvif p2p что это такое
Onvif протокол что это?
Классические камеры аналогового типа не имеют проблем с совместимостью. Можно приобрести устройство от любого производителя, подключить к нему видеорегистратор или другое устройство от другой компании. Никаких трудностей с синхронизацией оборудования не возникнет.
После появления специальных IP-камер, на раннем этапе формирования данных технологий, сразу же возникли определенные трудности. Они касались совместимости устройств от различных производителей. Это связано с тем, что каждая организация начала применять свой личный стандарт, применять индивидуальные протоколы. Оборудование могло синхронизироваться только от одного изготовителя, совмещение приборов от различных компаний сопровождалось возникновением проблем.
Для устранения сбоев в работоспособности было принято решение создать единый протокол. Он в считанные минуты решал возникающие проблемы.
ONVIF – это протокол, который предназначен объединить различное IP- оборудование (IP-камеры, видеорегистраторы) от разных производителей.
Основная цель протокола проста – чтобы видеонаблюдение не было привязано к одному производителю. Например IP-камера одного производителя, видеорегистратор другого.
Особенности общего стандарта безопасности
Разработка единого протокола для IP-камер была начата в 2008 году. Производители “Сони”, Bosch и Axis сделали стандарт, который был назван ONVIF (Open Network Video Interface Forum). Этот протокол предназначен для решения проблем, которые связаны с несовместимостью оборудования от разнообразных изготовителей. Теперь создать систему видеонаблюдения с помощью IP-камер можно было без особых проблем.
Open Network Video Interface Forum отличается специальным интерфейсом цифрового типа. Он объединяет множество форм взаимодействия устройств от разнообразных компаний-производителей:
Ежегодно протокол ONVIF обновлялся и усовершенствовался. В настоящее время имеется несколько стандартных версий, которые отличаются функциональностью.
Какие бывают профили ONVIF?
При создании стандарта ONVIF (на первоначальном этапе) основатели протокола столкнулись с определенными трудностями. Они были вызваны несовместимостью оборудования при использовании различных версий протокола. Именно поэтому производители приняли решение разработать специальную концепцию, которая получила название Profiles.
Концепция подразумевала разделение различных версий этого стандарта на профили. Они нужны для упрощения проведения проверок совместимости используемых приборов. Создать систему IP-видеонаблюдения можно было без анализа технических характеристик каждого устройства.
В настоящее время потребителям представлено шесть профилей стандарта ONVIF. Необходимо заметить, что последний из них находится на стадии диагностики. Создатели проверяют и исправляют ошибки, которые возникают в ходе его использования.
Стоит рассмотреть основные разновидности профилей стандарта ONVIF:
Именно профили ONVIF дали возможность с легкостью определять функциональность устройств, совместимость их с иными типами оборудования без проведения предварительного анализа данных. Профили существенно упростили процесс создания эффективных систем видеонаблюдения.
Чем отличается ONVIF от PSIA?
Протокол PSIA – это еще один стандарт, использование которого нацелено на решение проблем несовместимости. Он позволяет синхронизировать между собой различное IP-оборудование – камеры, датчика, системы КУД, устройства для видеоаналитики и управления информационной безопасностью.
Основная проблема стандарта PSIA – низкая популярность среди производителей оборудования для систем IP-наблюдения. В настоящее время количество организаций подключенных к протоколу PSIA составляет чуть более пятидесяти. Нужно заметить, что стандартом ONVIF пользуется более 500 фирм. Они реализуют более 5 тысяч наименований техники, которые поддерживают этот протокол.
Возможные проблемы, которые могут возникнуть при совместимости
Все производители единогласно утверждают, что проблем с совместимостью у реализуемой ими продукции не возникнет. Несмотря на это, при создании систем IP-видеонаблюдения можно столкнуться с определенными трудностями.
Одна из проблем – при монтаже, настройке камер для IP-наблюдения обнаруживается, что используемый видеорегистратор их не видит. Все устройства находятся в общей локальной сети, а датчики движения и иные программные функции напрочь отказываются выполнять возложенные функции. Сразу же возникает вопрос: «В чем причина сбоя?».
Трудности могут быть связаны с разнообразными причинами. Первоначально требуется удостовериться, что используемое оборудование поддерживает стандарт Open Network Video Interface Forum (ONVIF). Среди производителей встречаются мошенники. Они отмечают в своих продуктах поддержку протокола, но на самом деле это совсем не так. Чтобы исключить вероятность возникновения такого рода проблем, лучше приобретать оборудование у тех фирм-изготовителей, которые являются официальным представителем ONVIF. Эту информацию можно найти в сети.
Устройства, которые входят в систему IP-видеонаблюдения, могут быть несовместимы из-за использования различных профилей протокола. Одной поддержки ONVIF недостаточно. Это не указывает на то, что применяемое оборудование будет синхронизироваться. В данном случае вам потребуется убедиться, что приборы рассчитаны на работу с Profile S. Этот профиль является универсальным. Он позволяет совместить между собой различные версии ONVIF.
Протокол ONVIF осуществляет работу по стандартизации сетевого оборудования, существенно упрощает монтаж и расширяет возможности IP-систем безопасности. С помощью такого стандарта облегчается масштабируемость систем, открываются новые возможности для потребителя при выборе требуемого оборудования.
ONVIF имеет собственное программное обеспечение, которое позволяет раскрыть весь функционал используемого оборудования. Спецификация позволяет осуществлять поиск и выполнить подключение устройств, управлять телеметрией, передавать и записывать видео, настраивать изображения, проводить видеоаналитику в максимально сжатые сроки. ONVIF существенно увеличивает производительность оборудования.
PSIA и ONVIF: изучаем видеостандарты
Количество разных сетевых видеостандартов неуклонно растет, и у каждого из них есть свои преимущества и недостатки. Аджит Дубей (Ajit Dubey), старший руководитель проекта группы встроенных систем компании eInfochips, попытается найти отличия.
Спецификации стандартов
С ростом возможностей на рынке видеонабюдения появился и спрос на открытые стандарты. Благодаря компаниям, понимающим, что для созревания и расширения рынка IP-наблюдения требуются стандарты сетевых камер, в отрасли сформировались две организации – Форум открытого сетевого видеоинтерфейса (Open Network Video Interface Forum, ONVIF) и Альянс за совместимость систем физической безопасности (Physical Security Interoperability Alliance, PSIA).
PSIA и ONVIF были основаны в 2008 г. с разницей в несколько месяцев в целях создания стандартизированных интерфейсов для устройств физической безопасности и программных платформ. Обе организации преследуют единственную цель, а именно: создание совместимых систем безопасности на базе IP. Форум ONVIF возглавляют компании Axis Communications, Sony Corporation и Bosch Security Systems, демонстрирующие сегодня 14 совместимых сетевых видеоизделий от 9 компаний. Членами форума стали уже 103 компании, среди которых 12 полноправных членов, 13 членов-спонсоров и 78 членов – пользователей стандарта. ONVIF выпустили свой первый проект спецификаций в ноябре 2008 г.
PSIA является мировым консорциумом для более чем 50 производителей и системных интеграторов систем физической безопасности. В сентябре 2008 г. PSIA выпустил свою спецификацию, благодаря которой сегодня 8 компаний имеют совместимые продукты.
Сравнение ONVIF и PSIA
В отчете IMS Research (июль 2009 г.) говорится: «Компании – члены ONVIF контролируют более 40% мирового рынка видеонаблюдения по сравнению с 25% компаний в PSIA. Если углубиться в контекст оборудования для сетевого видеонаблюдения, то разница становится еще более поразительной. Видно, что компании, состоящие в ONVIF, контролируют примерно 60% рынка по сравнению с 20%, которые делят фирмы, входящие в PSIA».
Очевидно, что производители и интеграторы страдают от нерешительности в выборе, когда обе организации продвигают свои исключительные спецификации.
Кажется, что ONVIF сфокусировался на IP-видео, в частности, на камерах и аналитике, уделяя исключительное внимание интерфейсу между сетевым передающим видеоустройством (network video transmitter, NVT) и сетевым принимающим клиентом (network video client, NVC). Спецификация описывает обнаружение устройства, настройку устройства, событий, PTZ-протокола, видеоаналитику и функции потока в реальном времени. PSIA определила более общие спецификации для широкого рынка физической безопасности, который включает в себя контроль доступа, системы хранения и т. д.
Ниже приведены несколько различий между ONVIF и PSIA, которые могут повлиять на принятие того или иного стандарта для рынка IP-видеонаблюдения:
1. В основе спецификация ONVIF лежат стандарты web-сервиса. Web-сервис – это стандартизированный метод для интегрированных приложений, использующий независимые стандарты открытых платформ, таких как XML, SOAP, SOAP 1.2 и WSDL (WSDL 1.1) на базе IP сети. XML используется в качестве языка описания данных, SOAP применяется для передачи сообщений, а с помощью WSDL описываются непосредственно сервисы. SOAP является протоколом на основе XML сообщений и предназначен для кодирования информации в запросе web приложения и в ответе, прежде чем информация будет передана по сети. SOAP считается комплексным, но в то же время более сложным в использовании.
С другой стороны, PSIA использует архитектуру передачи состояния представления (representational state transfer, REST), которая является самым последним подходом, используемым сегодня практически во всех web-приложениях. REST проще в использовании по сравнению с SOAP и требует только простого XML-парсера с меньшей обработкой. Для архитектуры REST нужно меньше ресурсов, чем для SOAP. Еще одним преимуществом REST является возможность чтения сообщений протокола, которые легко интегрируются в систему отладки. Из-за высоких требований к вычислительным ресурсам и каналу передачи данных SOAP выглядит мене привлекательным для использования. Для SOAP нужны полностью совестимый HTTP-сервер, SSL и XML-парсер.
Например, для смены PTZ-позиции в ONVIF требуется SOAP-описание заголовка размером примерно 12 Кб. В PSIA же для изменения PTZ-позиции нужно всего лишь перейти по URL-адресу, что требует только нескольких байт.
2. Для сетевого поиска устройств в ONVIF используется механизм на основе технологии Microsoft-centric (WS Discovery). Это означает, что все ONVIF-совместимые устройства должны поддерживать WS Discovery, что, в свою очередь, гарантирует 100%-ную совместимость между устройствами в спецификации ONVIF при сетевом обнаружении друг друга.
В свою очередь, PSIA предлагает больше способов поиска устройств в сети, таких как Zeroconf, UPnP и Bonjour. Однако, несмотря на большую гибкость в выборе и использовании того или иного способа обнаружения, существуют и сложности в совместной работе устройств, поддерживающих PSIA. Например, PSIA-совместимую камеру с поддержкой Bonjour невозможно подключить к управляющей видеосистеме, отвечающей стандартам PSIA, но поддерживающей UPnP-метод. И все это несмотря на то, что и камера, и система обработки видео отвечают требованиям PSIA.
3. Система уведомления о событиях в ONVIF построена на основе WS-Notify. Эти требования четко регламентируют, каким образом камера должна передать информацию о событии на уровень выше по сравнению с обобщенным форматом сообщений для событий и уведомлений, указанным в PSIA. Это опять же не гарантирует 100%-ной совместимости устройств PSIA.
4. В PSIA-интерфейсе для интеграции аналитики проще, чем жесткие требования в ONVIF.
5. Благодаря REST-архитектуре реализация стандартов PSIA проще, нежели использование SOAP-структуры в ONVIF.
6. В PSIA уже сформированы требования к записи медиапотока и способу хранения, в то время как в ONVIF спецификация на систему хранения еще не определена. Возможно, она появится будущих версиях стандарта.
7. Поскольку требования PSIA охватывают больше аспектов физической безопасности, данный стандарт располагает техническими требованиями к интеграции систем управления информацией физической безопасности (PSIM).
Устанавливая стандарты
Хотя битва между ONVIF и PSIA за стандартизацию сетевых камер продолжается, при ближайшем рассмотрении можно увидеть, что оба стандарта похожи. Оба предлагают общие требования к устройствам управления и контроля для совместимости разных продуктов. В каждой спецификации присутствуют механизмы и направляющие для поиска и управления устройствами, настройки сети, аналитики и PTZ-функциями, а также вещания видеопотока по HTTP/RTSP и безопасности.
Производители могут использовать ONVIF-стандарт для профессиональных видеоустройств с аналитикой и конфигурированием камер.
Тем фирмам, кому требуется контролировать PTZ-устройства наряду с другими сервисами, такими как системы хранения и PSIM, можно использовать PSIA. Поскольку PSIA основан на REST-архитектуре, он больше подходит для остальных областей отрасли средств физической безопасности.
Не так уж сильно различается и структурная модель. Учитывая, что требования к сетевым камерам являются больше логическим стандартом, нежели физическим, не исключается вариант, что производитель применит к камере оба стандарта, или эти требования сольются в единое представление. Например, Cisco и Milestone поддерживают для своих решений обе спецификации. Компания eInfochips также планирует поддержку обоих стандартов для своего управляющего программного обеспечения, камер и DVR/NVR-устройств.
Всеобщая стандартизация сетевых камер непременно ускорит процесс интеграции и предоставит возможность совместной работы оборудования разных производителей. В итоге это позволит снизить затраты на системы видеонаблюдения.
Что такое ONVIF? И как его использовать при подключении камер в HomeKit через NodeRED
В продолжение к статье о подключении камер в HomeKit через NodeRed Евгений Олейник (permadm).
Далеко не всегда в инструкции IP камеры указывается описание RTSP протокола, с которым работает Ваша камера. Тем не менее, иногда возникает необходимость воспользоваться RTSP протоколом для подключения IP камеры к облачному серверу, настройки трансляции изображения на сайт или воспроизведения потокового видео в каком-нибудь плеере на вашем ПК или гаджете, или, в нашем случае, трансляции потока через плагин HomeKit в NodeRed. Рассмотрим все возможные способы, как узнать адрес RTSP IP камеры, если он не представлен в руководстве камеры. Если Ваша камера собрана из китайских xmeye комплектующих (что часто встречается на российском рынке, в том числе и у российских производителей ip камер HiQ, Vesta, SVplus и других бренды), то формат адреса RTSP камеры будет иметь следующий вид:
Если Ваша камера собрана из других комплектующих, то есть два способа, как узнать адрес RTSP потока вашей камеры.
Способ №1
Или пойти сложным путем и найти поток самостоятельно, с помощью прикладного программного обеспечения.
Используемый по умолчанию порт можно проверить в настройках камеры.
Способ №2
Еще раз о видеонаблюдении, камерах, RTSP, onvif. И «велосипед»!
Non-Interleaved Mode.
RTSP устанавливает связь и передает в камеру информацию о том «куда слать» данные (UDP порты).
Пример общения RTSP
Запоминаем
Transport: RTP/AVP;unicast;destination=10.112.28.33;source=10.112.28.231;client_port=49501-49502;server_port=6970-6971
Interleaved Mode.
Разница с Non-Interleaved Mode в том что все пакеты будут сыпаться в этот же порт.
Пример:
Запоминаем
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Теперь смотрим что и как.
Камеры шлют видео и аудио в разные RTP потоки. 2n поток — данные, 2n+1 поток — RTCP.
На видео нам идет 0 и 1 канал, на аудио 2 и 3 канал.
Теперь смотрим
Transport: RTP/AVP;unicast;destination=10.112.28.33;source=10.112.28.231;client_port=49501-49502;server_port=6970-6971
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
В первом случае указаны порты, во втором каналы.
С с Non-Interleaved Mode всё понятно. Просто RTP пакеты сыпятся в порты и их можно читать как то так:
DatagramPacket packet = new DatagramPacket(buffer, buffer.length);
s.receive(packet);
Проблемы начинаются с Interleaved mode.
По факту ни каких проблем быть не должно. По RFC мы ищем magic char «$», следующий байт — канал (он указывается в подключении 0-4 у нас) и 2 байта Length. Всего 4 байта.
Но есть не нормальные камеры. Например D-ling DCS-2103 «Досыпает» какие то данные после rtp пакета. frame дает размер 1448,
шлет 1448 фрейма, и после 827 байт какого то мусора. (Так делает Dlink DCS-2103 прошивка 1.00 и 1.20) 
И такое у «них» происходит постоянно. Этим частенько страдают китайские камеры. Qihan (356) этим не страдали.
Кроме как пропускать этот мусор идей больше нет.
В RTP сыпятся полезные данные. При DESCRIBE RTSP возвращается SDP пакет
Примеры SDP (h264, mjpeg, mpeg4):
Прочитать про SDP
Так как мода была mjpeg и текущая на h264, то рассмотрим их.
С MJpeg всё предельно ясно. А вот с H264 начинаются различия в камерах.
Формат h264 состоит из блоков с NAL заголовками (7.4.1 NAL unit semantics).
Чтобы можно было декодировать h264 необходимо помимо данных самого h264 иметь данные SPS (Sequence parameter set) и PPS(Picture parameter set). Первый описывает последовательность, второй параметры картинки. Так как сам кодек h264 знаю очень плохо, то большего описания не будет. SPS имеет тип 7, PPS 8. Без них невозможно декодировать h264.
Самое интересное — Qihan шлет SPS и PPS прям в RTP пакетах, Dlink не шлет их в RTP пакетах. Но SPS и PPS шлется в SDP пакете в параметре sprop-parameter-sets в кодировке base64.
sprop-parameter-sets=Z2QAKK2EBUViuKxUdCAqKxXFYqOhAVFYrisVHQgKisVxWKjoQFRWK4rFR0ICorFcVio6ECSFITk8nyfk/k/J8nm5s00IEkKQnJ5Pk/J/J+T5PNzZprQCgDLSpAAAAwHgAAAu4YEAAPQkAABEqjve+F4RCNQ=,aO48sA==
Шлются они через запятую
Вариант декодирования.
Так как камеры 720p или 1080p, то в 1 RTP пакет ни jpeg фрейм, ни h264 фрейм не поместится, то они режутся на пакеты.
RTP Payload Format for JPEG-compressed Video
RTP Payload Format for H.264 Video
JPEG
RTP пакет содержит main JPEG header
а дальше может варьироваться от Type и Q
Для декодирования jpeg нужно знать или вычислить quantization tables.
В моих камерах quantization tables шли в стартовом пакете Jpeg, по этому они просто брались оттуда.
Все вычисления есть в RFC.
Последний пакет фрейма вычисляется по RTP header Marker bit. Если он 1, то это последний пакет фрейма.
Single NAL Unit Packet
Это как раз SPS и PPS. Type=7 или Type=8
Если фрейм h264 не влезает в RTP пакет (1448 байт), то фрейм режется на фрагменты. (5.8. Fragmentation Units (FUs))
Type = 28
Эти заголовки следуют сразу после RTP заголовка
Для декодера h264 NAL — нужная информация. Если идет фрагментация фрейма, то NAL нужно восстанавливать. (FU)
нужно взять первые 3 бита из FU indicator и слить их с 5 последними FU header.
Теперь самое главное — сохраняем поток.
Jpeg
NON_IDR_PICTURE — необходим для декодирования, «разделяем» фреймы. (h264) Тут нужно меня поправить, так как это просто «костыль» и обоснований пока нет. Просто работает.
Получается такой поток: 00000001 + SPS + 00000001 + PPS + 00000001 + NAL…
erlyvideo: 0,0,0,1 — это префикс AnnexB записи H264. Это не часть H264 NAL-юнита, а разделитель между юнитами.
ну и обработка «всего» этого
в 2х словах. Получаем RTSP Interleaved Frame (например Channel: 0x00, 1448 bytes), читаем 1448 байт, делаем writeRawToStream, полиморфизм делает свое дело.
Дальше это нужно обкатать.
Казалось бы что для поддержания потока RTSP нужно делать RTCP отчеты, но нет, всё оказалось проще
Dlink, Qihan, VLC просто «едят» GET_PARAMETER:
шлем его раз в 55 секунд и всё.
При простом просмотре генерируется m3u файл и кормится в VLC
4
При склеивании ffmpeg клеит, после запускается VLC
5
Программа нарезает поток на файлы, интервал задается в настройках
Что делает ffmpeg:
Клеит
«Нормализует» (просчитывает заголовки и т.д.)
На выходе куча файлов
6
По хорошему можно писать в любой OutputStream
Git hub
Дальнейшей жизни программы может и не быть. Возможно допишу когда нибудь RTP классы для звука. (так как увлекаюсь до сих пор SIP)
Ну и самое вкусное.
Есть стандарт видео наблюдения ONVIF
Есть профессиональные железки, которые с камерами работают только по нему.
Есть камеры, которые работают по нему (Qihan, он же Proline), а ссылки rtsp приходится гуглить.
Есть опенсорсный продукт Onvif device manager для управления подобными железяками.
Я же в программу добавил поддержку onvif без авторизации и с авторизацией.
7
Git hub
Если пройтись по ссылкам выше, то можно получить всю документацию по Onvif.
Ответ:
Дальнейшее общение по onvif без авторизации идет в этом же ключе.
А вот пример общения но уже с авторизацией
Т.е. нужно слать заголовок. (тестилось на D-link DCS-2103, остальные камеры без авторизации работали, китай).
и пароль (Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) ))
Всё было сделано в образовательных целях. Если есть вопросы и вдруг понадобиться более подробное описание чего либо — пишите.
Надеюсь кому нибудь пригодится.
PS Не надо писать в комментариях про организацию на большую букву «I». Их Server использует SQLite, SSL, avcodec (ffmpeg), а в папке \Resources есть божественный файлик с названием camera_list.json, но моя наглость не позволила его прикрутить к своей программе 🙂 Но я не видел у них поддержку Onvif, видимо потому что они выпускают «свои» камеры. UPDATED: см комментарии от ivideon
Если прикрутить к программе OpenVPN и OpenCV, то будет забавное решение и «велосипед»
Ну и вот вам полезная ссылка на базу ссылок потоков камер