Протоколи и Стандарти в IP Видеонаблюдението – Пътеводител за Начинаещи

Може би си мислите, че не е важно да разбирате всички технически детайли зад работата на IP камерите. Обаче, ако сте любител на интелигентните домове като нас, ще откриете, че това познание може да е полезно.

Повечето самостоятелни камери за сигурност са създадени така, че всеки да може да ги инсталира и използва лесно (plug and play).

Това е страхотно, докато не решите да разширите системата си или преминете към записване извън облака. Тогава ще се сблъскате с множество термини, настройки и технически детайли, особено ако искате да свържете интегрирате продукти от различни производители или платформи с интелигентни устройства у дома.

Когато разгледахме пазара с всички тези протоколи и стандарти, трудността беше да разберем взаимодействието между различните компоненти. Нашата амбиция с този текст е да улесним поглъщането на информацията, представяйки ви основните термини и концепции в света на IP камерите.

Сега, нека се фокусираме върху ключовите елементи:

• Системни Спецификации: Това са “правилата” (индустриални стандарти), които определят как различните компоненти на видеонаблюдението ще комуникират помежду си – протоколи, формати на данните, методи на транспортиране и други. Въпреки че представляват общи принципи, не винаги са формално утвърдени като стандарти.
• Протоколи за Стрийминг и Контрол: Обикновено това са стандартизирани формати на данни за мрежова комуникация. Те улесняват прехвърлянето на информация и контрола на устройства, като действат като “езици” между тях.
• Видео и Аудио Кодеци: За оптимално предаване и съхранение на данни, те често се кодират в определени формати. Тези кодиращи и декодиращи алгоритми се наричат кодеци. Те могат да бъдат от различни типове, като някои са с отворен код, докато други са патентовани.

В зависимост от нуждите ви, тези компоненти могат да бъдат комбинирани по различни начини, за да осигурят желаното качество и функционалност на видеото и аудиото.

СИСТЕМНИ СПЕЦИФИКАЦИИ ЗА СИГУРНОСТ

В миналото видеонаблюдението и системите за сигурност в сгради главно се базираха на патентовани технологии, силно свързани с конкретния доставчик. През 2008 г. две независими групи компании се обединиха, с цел да стандартизират интеракциите между разните видове техника. Това доведе до появата на две отделни индустриални спецификации, които все още са актуални ONVIF и PSIA .

Тези две спецификации обхващат не само камери, но и друго оборудване като домофони, устройства за контрол на достъпа, електронни брави, сензори и други. Те не само определят как камерите стриймват, но и как се откриват и конфигурират устройства.

ONVIF – Форум за отворени мрежови видео интерфейси

Описание: ONVIF (Open Network Video Interface Forum) е стандартът, който най-вероятно ще срещнете при изграждане на ваша система за видеонаблюдение. Той се основава на отворени уеб стандарти като XML и SOAP.

Популярност: Поради своята широка база от членове-производители, ONVIF е станал много популярен и е често използвана спецификация. Обаче трябва да бъдете внимателни, тъй като не всички продукти, маркирани като “ONVIF-съвместими”, са наистина такива.

Сертификация: За да сте сигурни, че устройството ще работи правилно с ONVIF, е добре да проверите дали то е сертифицирано чрез официалния инструмент за проверка на съответствие.

Функционалност: Спецификацията на ONVIF се основава на различни софтуерни профили, които добавят функционалности към устройствата. Например, за IP камери може да намерите профили като G, M, S и T.

Преглед на Профилите за Системни Спецификации:

• А – Системи за контрол на достъп;
• C – Управление на вратите;
• D – Периферни устройства за контрол на достъпа;
• G – Локално съхранение и достъп до видео (Edge);
• M – Анализ на метаданни (разпознаване на лица, сканиране на регистрационен номер, контрол на стрийминг);
• S – Основно поточно видео;
• T – Усъвършенстван видео стрийминг (H.264/H.265, двупосочен звук, регистриране на движение/подправяне на събития).

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

PSIA – Алианс за оперативна съвместимост на физическата сигурност

PSIA (Physical Security Interoperability Alliance) представлява по-малка група, която обикновено е по-фокусирана върху професионално оборудване и големи системни интеграции. Изграден върху обща уеб REST архитектура, той използва различни методи за откриване като Bonjour, uPnP и Zeroconf. Поради това той не отговаря на ONVIF по отношение на оперативната съвместимост, тъй като различните PSIA устройства могат да използват несъвместими методи за намиране едно на друго.

Тъй като PSIA е по-затворен и не е толкова приложим за обикновените потребители, приемането му е по-бавно. Рядко се среща в потребителска техника, освен ако дадено устройство не поддържа и двата стандарта.

ПРОТОКОЛИ ЗА ПОТОЧНО ПРЕДАВАНЕ НА IP КАМЕРИ

Темата за протоколите при поточно предаване може да изглежда сложна и объркваща. По идеално би било, ако всеки протокол имаше строго определени функции, без прекалено припокриване. Но реалността не е толкова ясна.

Накратко имаме няколко различни роли, които трябва да покрием, когато искаме да предаваме данни от едно устройство на друго. Ключови функции при поточното предаване:

• Иницииране на поток: Това е процесът по установяване на връзка между устройствата, познат още като стартиране на сесия. Включва в себе си намирането на устройството, с което искаме да се свържем, и управление на тази сесия докато тя е активна.
• Управление на потоци: Тук се определят детайлите и параметрите на потока между двата участника в комуникацията.
• Поточно изпращане: Това са конкретните аудио и видео данни, които се изпращат, като се гарантира, че те ще достигнат до правилната дестинация.

Конкретният протокол, който се използва, често зависи от конкретните нужди на системата, както и от избора на разработчиците – например дали се работи в режим клиент/сървър или peer-to-peer.

RTSP – Протокол за Поточно Предаване на Данни в Реално Време

RTSP (Real Time Streaming Protocol) се явява като пионера сред протоколите за стрийминг, въведен още през 1996 г., в началната ера на Интернет. Въпреки че сега е дефиниран в IETF RFC 7826, той все още не е приет като официален стандарт. Въпреки това, RTSP е основният протокол използван за поточно предаване в спецификациите както на ONVIF, така и на PSIA.

В сравнение с HTTP, RTSP работи с текстови съобщения, но с ключовата разлика, че притежава състояние – тоест поддържа TCP идентификатор на сесия за следене на паралелната доставка на стриймове. Той е идеален за клиент/сървър настройки, като примерно свързване на IP камера с NVR. Тук става дума за предопределен източник и конкретен получател.

RTSP се фокусира върху комуникацията и управлението на сесията, но не се занимава с прехвърлянето на реалните данни от потока. За тази цел той зависи от друг протокол. Също така, не предлага възможности за криптиране на данните.

Можем да разгледаме подобни контролни протоколи като дистанционни управления, които изпращат инструкции до източника, за да започне да регулира или прекъсва потока.

Един пример за команда “PLAY” изглежда така:

PLAY rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 4
Range: npt=5-20
Session: 12345678

Имайте предвид, че поради взаимосвързаността на тези комуникации между устройствата, RTSP е способен не само да инициира, но и да управлява сесията. Това означава, че ако стриймът трябва да се показва на устройство, което не го поддържа, например компютър или мобилен телефон, често стриймът ще бъде “препращан” чрез различен метод от RTSP клиента.

SIP – Протокол за иницииране на сесия

SIP (Session Initiation Protocol) е текстов протокол, който стана популярен с нарастването на VoIP комуникациите. Може да се счита за конкурент на RTSP в някои отношения, тъй като те изпълняват подобни роли, но фокусът е върху връзките между партньори. Обикновено е предпочитан за облачно базирани потребителски камери като тези на Ring, тъй като поддържа преходни (ad hoc) поточни връзки между произволни устройства.

В процеса на конфигуриране на сесията, клиентите (наречени потребителски агенти) се основават на допълнителен протокол, известен като SDP (Session Description Protocol). Това е нещо като визитна картичка, която съдържа проста текстова дефиниция на информацията за адресиране и наличните протоколи, които се отнасят до този клиент.

SIP беше създаден от онлайн обществото и вече е признат като стандарт, въведен първоначално в RFC2543 през 1999 г. Подобно на RTSP, основната му цел е настройката на многопоточни сесии за предаване на гласови и видео данни, но той действително не прехвърля поточните данни. Различно от RTSP, SIP има възможности за криптиране, тъй като е предназначен за интернет употреба. Криптирането е осъществено чрез TLS, аналогично на начина, по който HTTP трафикът се криптира между сървър и клиент.

SIP командите са формулирани подобно на HTTP, но вместо команди като GET и POST, имаме операции като INVITE, UPDATE и BYE. Аналогично на HTTP, тези заявки ще предизвикват различни 3-цифрени отговорни кодове, които информират другата страна за резултата от заявката.

Примерен формат за SIP покана:

INVITE sip:Manager@stations2.work.com SIP/2.0
From: Daniel<sip:Collins@station1.work.com>;tag=abcd1234
To: Boss<sip:Manager@station2.work.com>
CSeq:1 INVITE
Content-Length: 213
Content-Type: applications/sdp
Content-Disposition: session

v=0
o=collins 123456 001 IN IP4 station1.work.com
s=
c=IN IP4 station1.work.com
t=0 0
m=audio 4444 RTP/AVP 2 4 15
a=rtpmap 2 G726-32/8000
a=rtpmap 4 G723/8000
a=ftpmap 15 G728/8000
m=video 6666 RTP/AVP 34
a=rtpmap 34 H263/9000/2

MQTT – Телеметричен транспорт на опашка от съобщения

Message Queuing Telemetry Transport протоколът може да изглежда като отклонение от основната тема, но заслужава споменаването си поради приложимостта му в определени контексти на поточно предаване.

Създаден още през 1999 г., MQTT е компактен протокол за съобщения, особено подходящ за IoT устройства. Благодарение на своята лекота, той е идеален за устройства с ограничени ресурси. Въпреки че не е специфичен протокол за управление на потоци, двупосочният му характер позволява иницииране на сесии и управление на свързани функции на камерата, например известия при срабатване на сензори, детектиране на движение или изпращане на статични кадри.

Значимостта на MQTT в тази статия идва от възможността му да поддържа настройки за WebRTC потоци.

WebRTC – Комуникации през уеб в реално време

През 2010 г. Google придобива ключовите технологии зад този протокол Web Real-Time Communications и го преобразува в отворен код, като така дава старт на процеса на стандартизация. Първата реализация на WebRTC започва през 2011 г., като достига статус на препоръчителен стандарт през 2021 г. Благодарение на широкото приемане от страна на уеб браузърите, WebRTC де факто стана стандарт за поточно предаване.

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

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

Въпреки всичко, WebRTC не носи самия поток на данните, а организира и управлява съответната сесия. Във връзка с другите протоколи като SIP или MQTT, WebRTC действа като мост, тъй като няма способност за автоматично откриване и функционира само между предварително известни точки. Поради това често се комбинира с други протоколи за комуникация, като SIP, за да се инициира сесията.

С цел унификация на поточното предаване между различни браузъри, WebRTC определя стандартен набор от кодеци, които трябва да бъдат поддържани от всички браузъри. От гледна точка на видео, стандартните кодеци включват H.264 и VP8, като VP9 е предоставен като допълнителна опция. Относно аудиото, основните кодеци са Opus и G.711, докато G.722, iLBC и iSAC се предоставят като допълнителни опции.

RTP – поточно предаване в реално време

Това е мястото, където гумата среща пътя. Докато гореспоменатите протоколи управляват и конфигурират сесията за поточно предаване, само Real-time Transport Protocol фактически пренася видео и аудио данни. Той служи като транспортен механизъм, пренасящ кодирани аудио и видео сигнали от източник до получател. RTP беше въведен през 1996 г. и последната му стандартна дефиниция е от 2003 г., определена в RFC 3550.

RTP е приет стандарт и е предпочитаният транспортен протокол за RTSP, SIP и WebRTC. Разбира се, в специфични контексти могат да се използват и други протоколи, ако те предлагат определени характеристики.

Съпътстващият протокол RTCP (Real-Time Transport Control Protocol – Протокол за контрол в реално време) допълва RTP, като предоставя механизъм за мониторинг на аспекти като загуба на пакети, скорост на предаване и динамична промяна на резолюцията на видеото. Този контрол се осъществява извън основния поток, което гарантира, че не пречи на основното предаване на данни.

Тъй като аудио и видео потоци често се предават чрез отделни RTP сесии, RTCP улеснява тяхната синхронизация в крайната точка и мониторинга на качеството на услугата. RTP сам по себе си не гарантира определено качество, а просто предава данните така, че те да могат да бъдат обработени от други системи или протоколи, като например WebRTC.

Важен аспект на RTP е, че е независим от медийния формат. Това означава, че не изисква актуализации при появата на нови медийни формати. Всяка медийна характеристика се определя от специфичен профил, указващ нужните кодеци. Има редица RFC документи, описващи как различни медийни формати, като MPEG-4 и H.263, се интегрират с RTP пакети.

В повечето случаи RTP използва UDP, тъй като някои загуби при поточните данни са приемливи, но своевременното им доставяне приоритет. RTCP, от друга страна, често използва TCP за управление на връзката и информацията за сесията, както е при RTSP. Всяка RTP медийна единица се инициира със заглавка, в която са включени профилните указания и форматиращи данни.

Всяко поле с данни се дефинира, както следва:

• Версия – използваната версия на протокола.

• P (Padding) – Padding може да се използва за осигуряване на определен размер на блока. Последният байт е броят на добавените байтове за допълване.

• X (Extension – Разширение) – Отбелязва, ако за някои профили е необходим хедър на разширение.

• CC (CSRC брой) – Броят на CSRC идентификаторите (вижте по-долу).

• M (Marker – Маркер) – Ако е зададено, текущите данни имат специално значение за приложението.

• PT (Payload type – Полезен товар) – Показва формата на полезния товар, както се изисква от конкретния профил.

• Sequence number (Пореден номер) – Увеличава се за всеки пакет, използван за откриване на загуба на пакет. Първоначално това е произволна стойност за предотвратяване на щафетни атаки.

• Timestamp (Времево клеймо) – използва се от приемника за възпроизвеждане на получените проби в подходящо време и интервал. Значението на тази стойност зависи от типа на потока, като например 8KHz за аудио с качество на телефонията или 90kHz за видео потоци. Това е посочено в профила на медията.

• SSRC – Идентификаторът на източника на синхронизация уникално идентифицира източника на поток.

• CSRC – Идентификатори на допринасящи източници Може да има множество допринасящи източници към поток, чийто брой е посочен в полето CC по-горе. Всеки от тях ще има собствено CSRC поле.

• Header extension (Заглавка на разширението) – (незадължително, присъствието се указва от полето за разширение ) Първата 32-битова дума съдържа специфичен за профила идентификатор (16 бита) и спецификатор на дължина (16 бита), който показва дължината на разширението в 32-битови единици, с изключение на 32-те бита на заглавката на разширението.

ВИДЕО КОДЕЦИ ЗА КОМПРЕСИРАНЕ

Данните, пренасяни от протоколите за поточно предаване към приемник, независимо дали са за гледане или запис, трябва да бъдат компресирани по някакъв начин. Суровите видео данни са по-големи и консумират ненужна честотна лента, която не можем да си позволим да губим, ако искаме бърза, висококачествена емисия.

Кодекът (съкращение от „кодер-декодер“) е технологичен инструмент, който извършва тази компресия по уникален начин и позволява декомпресирането от другата страна. Този процес на преобразуване се нарича „кодиране“. Съвременните кодеци са изключително ефективни при намаляване на размера на данните, без значителна осезаема загуба на качество.

Има няколко популярни кодека, които ще се използват за поточно предаване в сценарии с IP камера. Могат да се използват различни кодеци за самото предаване на камерата и възпроизвеждането от NVR. Изборът на кодек зависи от устройството, което възпроизвежда потока. Преобразуването на видео от един формат в друг е наречено „прекодиране“.

Най-разпространени видео кодеци

• H.264/AVC – Представен от ITU и познат като MPEG-4 AVC, H.264 се използва отдавна и е станал основен стандарт за интернет видео. Той е съвместим с множество устройства и предоставя висококачествено видео при много по-нисък обем от MEPG-2. Въпреки това, той започва да отстъпва място пред по-нови стандарти с повече капацитет и по-висока разделителна способност.
• H.265/HEVC – Подобрена версия на H.264, тази платена технология предлага подобрено качество при същия размер и е подходяща за 4K видео. Макар да не е безплатен, новите безплатни алтернативи го притискат и изтласкват от пазара.
• VP8/VP9 – Създаден от Google за оптимизация на уеб потоци и избягване на такси. Този кодек е безплатен и е изборът на Youtube. Той предоставя сравними характеристики с H.265 и работи отлично с 4K качество.
• AV1 – Създаден от индустриалния съюз AOM, която включва главните технологични лидери, AV1 е предназначен да замести съществуващите поточни стандарти, като предоставя по-добър резултат от HEVC с 30% повече ефективност. Той е в състояние да създаде най-висококачествен поток при всякаква честотна лента в сравнение с други протоколи и има одобрението на всеки голям уеб браузър, технологична компания и производител на хардуер. Въпреки това все още е сравнително нов и новите стандарти са известни с бавното набиране на скорост. Приемането все още е сравнително малко, но сега е в добра позиция да расте по-бързо.

Не забравяйте, че аудиоданните се компресират с други кодеци и след това се синхронизират с видеопотока от софтуера (приложението) за възпроизвеждане.

СВЪРЗВАНЕ КЪМ RTSP КАМЕРА

NVR устройства, които са съвместими с RTSP/ONVIF камери, често ви предоставят опцията да персонализирате настройките за всяка отделна камера. Основният нюанс при работа с RTSP е, че точният URL адрес за свързване може да се различава според марката на камерата. Макар че тази информация обикновено може да бъде намерена в ръководството на камерата, съществуват и общодостъпни източници, от които можете да извлечете необходимите данни.

Ето стандартния формат за свързване чрез RTSP:

rtsp://[username:password]@[ip_address]:[port]/[suffix]

ip_address – Това е IP адресът на вашата камера в локалната мрежа.

port – По подразбиране е 554, но ще бъде различно само ако се свързвате към публикувана в интернет камера.

suffix – Този сегмент от адреса е уникален за всеки производител и често определя конкретния канал за свързване или други параметри на камерата.

Няколко примера:

rtsp://admin:12345scw@192.168.1.210:554/cam/realmonitor?channel=1&subtype=1

rtsp://admin:12345@192.168.1.210:554/Streaming/Channels/101

rtsp://admin:12345scw@192.168.1.210/unicast/c2/s2/live

rtsp://192.168.1.210:554/LiveChannel/0/media.smp

rtsp://192.168.1.210/h264.sdp

РЕЗЮМЕ

IP камерите, включително много Wi-Fi модели , могат да се използват не само с хардуерни DVR, но и с разнообразен софтуер и услуги за стрийминг. За оптимално използване на тези решения е нужно добро разбиране на протоколите или поне основно запознаване с интерфейса.

Поточно видео от тези камери обикновено използва RTP протокола за пренасяне на кодираното видео и на този етап камерите използват основно H.264 за кодиране. Управлението на RTP данните може да бъде осъществено чрез различни протоколи, сред които RTSP и SIP са стандарт за свързване на камерата към NVR, RTSP е предпочитан за локални NVR системи, докато SIP често се използва за облачни решения. Възпроизвеждането или повторното излъчване от NVR може да се управлява от WebRTC, тъй като позволява широк междуплатформен достъп в уеб страници и приложения за смарт телефони.