что такое onvif в камерах видеонаблюдения
Еще раз о видеонаблюдении, камерах, 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, то будет забавное решение и «велосипед»
Ну и вот вам полезная ссылка на базу ссылок потоков камер
Что такое ONVIF протокол?
Аналоговые камеры видеонаблюдения не имели никаких проблем совместимости – можно было купить камеру от любого производителя и использовать ее с видеорегистратором от другого – никаких трудностей при этом не возникало. С появлением IP камер на раннем этапе развития технологии возникали определенные затруднения, касающиеся совместимости оборудования для видеонаблюдения от различных производителей, которые были обусловлены тем, что каждая компания использовала свой собственный стандарт/протокол. В связи с этим, оборудование от одного производителя было полностью совместимо между собой, но при попытке совмещения устройств от разных производителей начинались проблемы. В связи с этим было принято решение разработать единый протокол, который бы решил данную проблему.
Содержание:
Создание общего стандарта безопасности для IP камер
В 2008 году компании Sony, Bosch и Axis разработали стандарт под названием Open Network Video Interface Forum (ONVIF). Данный стандарт призван решить проблему несовместимости оборудования различных производителей для упрощения создания системы видеонаблюдения на базе IP камер. Протокол ONVIF имеет стандартизированный цифровой интерфейс оборудования для видеонаблюдения, и объединяет в себе такие аспекты взаимодействия оборудования, как:
В процессе развития ONVIF претерпел некоторые изменения и сегодня имеет много стандартных версий:
Профили ONVIF
На начальном этапе работы стандарта ONVIF возникли определенные трудности, вызванные несовместимостью различных версий протокола. В связи с этим была принята концепция «profiles», которая подразумевает разделение версий ONVIF протокола на определенные профили для упрощения проверки соответствия оборудования для IP видеонаблюдения без необходимости анализа технических деталей устройств.
Основные профили стандарта ONVIF
На сегодняшний день существует 6 профилей стандарта ONVIF, последний из которых находится пока в стадии тестирования:
Профиль G протокола ONVIF
Итак, принятие профилей ONVIF позволило легко определять функции, поддерживаемые тем или иным устройством без необходимости анализа совместимости между версиями ONVIF.
ONVIF против PSIA
PSIA является еще одним стандартом, нацеленным на решение проблемы несовместимости между оборудованием для IP видеонаблюедния – камерами, датчиками, системами КУД, видеоаналитики, управления информационной безопасностью, и т. д. Основной проблемой данного стандарта является его низкая популярность – на сегодняшний день количество подключенных компаний составляет около 50, когда как ONVIF насчитывает более 500 членов, которые предлагают более 5000 тыс. продуктов, поддерживающих ONVIF протокол.
Проблемы с совместимостью
Несмотря на то, что производители оборудования утверждают, что оно совместимо со стандартом ONVIF, иногда возникают определенные проблемы. Например, при попытке установки и настройки камер видеонаблюдения, обнаруживается, что видеорегистратор напрочь отказывается их видеть, находясь при этом в той же локальной сети, либо не работает датчик движения или любые другие программные функции. С чем же связаны подобные трудности?
Во-первых, вы должны полностью удостовериться, что все ваши устройства действительно поддерживают ONVIF протокол. Некоторые производители часто отмечают свои продукты, как совместимые с ONVIF протоколом, хотя на деле оказывается, что это далеко не так. Для минимизации риска несовместимости лучше всего использовать оборудование для видеонаблюдения от производителей, имеющих официальное членство в ONVIF.
Во-вторых, несовместимость может вызываться различием профилей оборудования. Одна только поддержка ONVIF еще не означает, что устройства будут совместимы между собой. Для полной уверенности необходимо убедиться, что все оборудование вашей системы поддерживает Profile S, так как наличие поддержки данного профиля увеличивает вероятность совместимости по всем основным параметрам любой версии ONVIF.
Что такое протокол Onvif в ip-камере
Несмотря на резкую утрату своей популярности в наши дни, камеры видеонаблюдения аналогового типа все же имели определенные преимущества. Среди главных плюсов стоит выделить простую совместимость нескольких устройств от различных производителей. Не синхронизация, а сказка! Это значительно упрощало задачу неопытным пользователям.
Но, как известно, мир не стоит на месте. Все развивается, и весьма стремительными темпами. Ныне мы наблюдаем настоящий расцвет цифровых и сетевых технологий. Гаджеты становятся компактнее, функциональнее и умнее. Чтобы работать с прогрессивным оборудованием, нельзя отставать от времени.
Onvif (Open Network Video Interface Forum) — это протокол, который создавался для объединения IP-устройств разных производителей. Таких как IP-камеры, видеорегистраторы dvr и другие.
Создание стандарта для цифровой камеры
Аналоговые системы видеоконтроля отошли на второй план, уступив дорогу бюджетным китайским устройствам – видеорегистраторам и цифровым камерам. Владельцу таких устройств не помешает вооружиться некоторыми знаниями. В этой статье мы затронем актуальную тему совместимости новомодных продуктов.
Еще не так давно этот процесс казался сложным, витиеватым или совершенно невозможным. Почему так происходило?
Ответ: на то время производители использовали разные протоколы. Нужно совместить несколько устройств от одного производителя? Никаких проблем! Трудности начинались при попытке совмещения гаджетов от разных компаний. Оборудование не хотело нормально работать.
Решением данного вопроса послужил протокол под названием ONVIF. За его разработку взялись сразу три крупных компании – Bosh, Sony и Axis. Протокол ONVIF появился в 2008 году, и сразу же решил проблему несовместимости различных гаджетов. Владельцы IP-камер смогли выдохнуть с облегчением.
Самое интересное, что по аналогии с названием стандартного протокола нарекли целую организацию международного типа.
Кто может стать членом организации:
Вернемся к обсуждению протокола. По своей функциональности он отдаленно напоминает API производителей устройств. Ключевая задача ONVIF заключается в стандартизации базового функционала гаджета. С его появлением многое стало доступнее и проще.
Теперь покупатель не тратит уйму времени на выбор и поиски оборудования от одного производителя. Он может купить то, что ему нравится или приходится по карману, не обращая особого внимания на марку производителя. Разработка стандартного протокола сделала рынок еще более популярным и доступным.
Важно! с 2008-го по 2014-й год появилось несколько версий ONVIF, которые были заархивированы в 2016 году. С тех самых пор многое усложнилось. Теперь стандартный протокол позволяет совместить последние версии устройств. Будет ли ONVIF совместим с архивной версией другого устройства – вопрос открытый, и комментариям не подлежит. Тем не менее, эту информацию нужно учесть при выборе оборудования для системы видеоконтроля.
До 2016 года версии протокола отличались между собой цифрами. Например, версия 2.4. Позже появились профили ONVIF. На сегодняшний день пользователям доступны 5 готовых профилей, и еще 1 профиль, находящийся на этапе диагностики. И хотя он доступен для использования, разработчики считают этот продукт «сырым», а поэтому продолжают исправлять различные баги.
Профили и их предназначение
Что делать, если возникли проблемы с совместимостью оборудования
Часто случается так, что производители любят рассказывать сказки своим клиентам. Они громогласно обещают одно, а в результате – совершенно иной исход событий. Вдруг выясняется, что некоторые их устройства не совместимы с протоколом ONVIF.
Пользователь пытается установить и настроить систему видеоконтроля, и понимает, что его регистратор попросту не желает видеть камеры. И всё это – в одной локальной сети.
Иногда в процессе подключения отказывают важные программные функции, без которых невозможно наладить нормальную работу системы. Что предпринять, если произошла такая неприятность?
Рекомендация пользователю: при покупке нового устройства проверьте, является ли конкретная компания-производитель членом организации ONVIF. Если это так, то подобных проблем с гаджетом возникнуть не должно. При такой бдительности клиент сам снижаете риск быть обманутым.
Заключение
Стандартный протокол, разработанный для IP-устройств, сделал эту нишу сильнее и прогрессивнее. Нынешние возможности, предоставленные потребителю, просто впечатляют!
Как подключить IP камеру по Onvif или RTSP?
1. ONVIF 
Начнем с протокола ONVIF (Open Network Video Interface Forum).
ONVIF — это общепринятый протокол для совместной работы IP-камер, видеорегистраторов NVR, программного обеспечения, на случай, если все устройства разных производителей.
Убедитесь, что подключаемые устройства имеют поддержку ONVIF, на некоторых устройствах ONVIF может быть выключен по умолчанию.
Либо может быть отключена авторизация по ONVIF это значит, что логин/пароль будет всегда по умолчанию независимо от логина/пароля для WEB.
Также стоит отметить, что некоторые устройства используют отдельный порт для работы по протоколу ONVIF. В некоторых случаях ONVIF-пароль может отличаться от пароля для WEB-доступа.
Что доступно при подключении по ONVIF?
Эти параметры зависят от совместимости версий протокола ONVIF. В некоторых случаях часть параметров недоступна или работает некорректно.
Разберем пример подключения камеры к видеорегистратору OMNY с использованием ONVIF:
Камеры OMNY PRO и OMNY Base используют ONVIF—порт 80, в регистраторе он указывается как Порт устройства/HTTP-порт (На моделях OMNY PRO до 2017 года ONVIF-порт 8080).
TCP — устанавливает соединение между отправителем и получателем, следит за тем, чтобы все данные дошли до адресата без изменений и в нужной последовательности, также регулирует скорость передачи.
В отличие от TCP, UDP не устанавливает предварительного соединения, а вместо этого просто начинает передавать данные. UDP не следит чтобы данные были получены, и не дублирует их в случае потерь или ошибок.
UDP менее надежен, чем TCP. Но с другой стороны, он обеспечивает более быструю передачу потоков благодаря отсутствию повторения передачи потерянных пакетов.
Второй способ подключения — это RTSP (Real Time Streaming Protocol).
RTSP-потоковый протокол реального времени, в котором описаны команды для управления видеопотоком. С помощью этих команд происходит трансляция видеопотока от источника к получателю. Например, от IP-камеры к видеорегистратору или серверу.
Что доступно при подключении по RTSP?
Преимущество этого протокола передачи в том, что он не требует совместимости по версиям. На сегодняшний день RTSP поддерживают практически все IP-камеры и NVR.
Недостатки протокола в том, что кроме передачи видео- и аудиоданных больше ничего не доступно.
Разберем пример подключения камеры к видеорегистратору OMNY с использованием RTSP:
Пример запроса для OMNY BASE:
Зачем нужен дополнительный поток?
На локальном мониторе, подключенном к регистратору в мульти-картинке, регистратор использует дополнительный поток для экономии ресурсов. К примеру, в маленьких картинках по 16 окон совсем не обязательно декодировать Full HD разрешение, достаточно D1.
Ну а если Вы открыли 1/4/8 окон, то в этом случае декодируется основной поток с высоким разрешением.
3. Не получается подключить по ONVIF
Если не получается подключить IP камеру в ПО или NVR по ONVIF, нужно убедиться:
ONVIF Device Manager
Проверить работоспособность ONVIF в камере, вы можете через независимое ПО ONVIF Device Manager. Для проверки правильности параметров ONVIF необходимо использовать ODM в локальной сети, исключив другие ПО и NVR.
Бюджетное видеонаблюдение для прижимистых «чайников»
Скоро будет 7 лет с момента написания статьи «Видеонаблюдение под Ubuntu для «чайников» (ZoneMinder)». За эти годы она не раз корректировалась и обновлялась в связи с выходом новых версий, но кардинальная проблема, а именно — стоимость IP видеокамер, оставалась прежней. Её обходили оцифровывая аналоговые потоки и эмулируя IP камеры с помощью USB «вебок».
Ситуация изменилась с появлением китайских камер стандарта ONVIF 2.0 (Open Network Video Interface Forum). Теперь любую камеру отвечающую стандарту вы можете настроить с помощью ONVIF Device Manager.
Более того, вы сразу можете увидеть адреса и параметры потоков вещания с камеры. Да, да. Теперь потоков, как минимум — 2, не считая звука. Один архивный — в максимальном качестве, другой — рабочий в меньшем разрешении.
Я буду рассказывать на примере камеры MISECU IPC-DM05-1.0 Купил её в «чёрную пятницу» по цене 1059,15 руб. Сейчас они подняли цену и я бы скорее приобрел GADINAN. Что в прочем, одно и то-же. В любом случае, аппаратная часть моей камеры определяется как hi3518e_50h10l_s39 не зависимо от того, какой логотип написан на коробке. Камера купольная, по факту представляет из себя шарик «на верёвочке» легко вынимаемый из гнезда-держателя. Если будете заказывать, обратите внимание, что блок питания надо покупать отдельно (DC 12V/2A). Я использовал БП от сгоревших китайских-же настольных часов. К сожалению, звука и управления позицией в камере нет. Для этих целей подойдет какой-нибудь беби-монитор типа этого или этого. Главное, что бы в названии было слово Onvif.
После распаковки и включения надо выставить IP адрес каждой камеры (по умолчанию у всех жестко 192.168.1.10), чтобы они не конфликтовали между собой. Это можно сделать в ONVIF Device Manager или штатной утилитой General Device Manage которая идет в комплекте, на мини CD. Далее, выставляем временную зону, параметры отображения дат и имя для каждой камеры. Создаем пользователей с правами «только для просмотра».
Веб-интерфейс камеры, программы CMS и интерфейс облака в браузере совершенно одинаковы, неудобны и требуют IE c ActiveX.
Благо, их можно с успехом заменить приложением XMeye установленным на Android или iOS. Но, прежде необходимо сделать нашу камеру видимой для облака. Для этого откройте порт по которому работает Onvif (8899) на вашем коммутаторе. В моём случае — это NAT Setting-Virtual Server. Если камер несколько, то внутренний порт для каждого IP оставляете прежним, а внешний меняете на пару значений. Далее, камера сама постучится в облако и предъявит свой индивидуальный CloudID. Вам нужно будет только добавить его в свой профиль в облаке.
Собственно, сама по себе камера уже может детектить движение, стримить видео и отправлять аллармы. Вкупе с облачным сервисом XMeye — это готовый сервис мониторинга.
Если вам хочется иметь свой собственный регистратор с архивами, и вы любите Windows, то ставьте бесплатные iSpy, или SecurOS Lite (до 32 камер) или бесплатную-же версию (до 8 камер) Xeoma. Кстати, у последней есть версии для Mac OS X, Linux включая ARM и Android.
С настройками не должно возникнуть проблем, так что можете дальше не читать. Остальная часть статьи написана для Linux.
Я был приятно удивлен обнаружив в Zoneminder v.1.30.0 визард для настройки ONVIF камер. Он позволяет подключить к консоли любой из потоков идущих с камеры в зависимости от аппаратных возможностей и потребностей оператора.
Установка и настройка Zoneminder никогда не были лёгким занятием. Последняя версия вышла особо капризной и требует предварительной установки веб-сервера LAMP, с последующим выполнением ряда дополнительных действий. Поэтому, приведу старый «джедайский» способ подключения камеры для более старых версий:
1. Определите адреса потоков через ONVIF Device Manager или Xeoma. У вас должно получиться что-то похожее:
Не забудьте заменить звездочки (*) своими данными.
2. Проверьте адреса в проигрывателе VLC. Меню-Медиа-Открыть IRL