У випадку складнощів з налаштуванням або експлуатацією продукції, ознайомтеся з запитаннями та відповідями на них, що часто задаються.


Як отримати подарункову ліцензію REVISOR VMS?

Для отримання подарункової ліцензії Revisor VMS дотримуйтесь інструкцій. Завантажити інструкцію.


У мене 1,3 Мп IP-камера RedLine. Намагаюся встановити ActiveX, але виникає помилка "HTTP 404 - не знайдено", що робити?

У 1.3 Мп відеокамерах модуль ActiveX не вбудований, його необхідно встановити з диска, що йде в комплекті або завантажити за посиланням

Для камер 4MP:

rtsp://admin: [email protected]адреса:554/ch01/0 - основний потік

rtsp://admin: [email protected]адреса:554/ch01/1 - додатковий потік

rtsp://admin: [email protected]адреса:554/streaming/mjpeg - потік mjpeg

Для камер 1,3MP та 2MP

rtsp://admin: [email protected]адреса:554/streaming/video0 - основний потік

rtsp://admin: [email protected]адреса:554/streaming/video1 - додатковий потік

Яке програмне забезпечення підходить для мобільних пристроїв?

Які порти потрібні для роботи через мережу?

80 - web інтерфейс

554- rtsp (відео) потік

4900 – моб. порт

9988 - Для клієнтських підключень до 4MP IP-камер

Що робити, якщо не працює звук на реєстраторі або в сторонньому програмному забезпеченні?


Для передачі звуку необхідно в налаштуваннях у вкладці МЕРЕЖА - RTSP потік, активувати передачу аудіо.

Обсяг займаного простору залежить від обраної якості запису та частоти руху (при записі за детекцією). Для розрахунку архіву можна використовувати Disk calculator.

Як знайти IP-камеру в локальній мережі?

Встановіть програмне забезпечення та запустіть його від імені адміністратора. У вікні Ви побачите список обладнання, підключеного в локальну мережу.

Для зміни налаштувань мережі необхідно вибрати обладнання у верхньому полі та в нижньому полі вказати налаштування мережі (IP-адресу, маску, шлюз), ввести ім'я користувача, пароль та натиснути кнопку Modify. Надалі для підключення необхідно використати заданий IP

.

Для 1,3MP та 2MP IP-камеррекомендується використовувати

Як додати 1.3 MP IP камеру в CVMS?

Якщо камера знаходиться в локальній мережі, то в режимі перегляду в меню Пристрої (ліворуч) натиснути правою кнопкою та вибрати "Швидкий пошук", потім вибрати потрібну камеру та вказати пароль.

Якщо підключення буде здійснюватися через інтернет, то в режимі перегляду в меню Пристрої (ліворуч) натиснути правою кнопкою і вибрати "Додати пристрій" і ввести дані для підключення, НЕОБХІДНО ВКАЗАТИ ПОРТ TCP (за замовчуванням 1115)

Зручний перегляд відеотрансляції або можна налаштувати за допомогою програмних мультимедійних плеєрів на вашому персональному комп'ютері. Сьогодні ми розглянемо, як налаштувати потік RTSP для мережевого обладнання Dahua Technology в одному з найпопулярніших плеєрів VLC Media Player.

RTSP (Real Time Streaming Protocol – потоковий протокол реального часу) – протокол, що дозволяє користувачеві віддалено відтворювати потік мультимедійних даних (аудіо та відео) за допомогою гіперпосилання та мультимедійного плеєра (у нашому випадку VLC Media Player).

Якщо у вас виникла потреба в налаштуванні відеопотоку, скористайтеся такими кроками:




  1. Перш за все, необхідно завантажити та встановити VLC Media Player, який доступний на офіційному сайті у вільному доступі.
  2. Клацніть пункт меню Media (Медіа) – Open Network Stream (Відкрити URL).
  3. Введіть мережну адресу RTSP у рядок, що радить.
  4. Натисніть кнопку відтворення, коли на екрані з'явиться відео.

Розшифрування посилання RTSP

Приклад:

rtsp:// :@:/cam/realmonitor?channel= &subtype=

Де:

: ім'я користувача (логін)

: пароль.

: IP-адреса мережевої відеокамери.

: за замовчуванням виставлено порт 554. Цим значенням можна знехтувати.

: номер каналу. Нумерація починається з першого.

Тип потоку. Значення головного потоку дорівнює 0, додаткового потоку 1 дорівнює 1, додаткового потоку 2 дорівнює 2. Наприклад, посилання для додаткового потоку номер 1 матиме такий вигляд:

rtsp://admin: [email protected]:554/cam/realmonitor?channel=1&subtype=1

IP-відеокамери Dahua Technology підтримують протоколи передачі даних TCP та UDP. Якщо порт 554 змінено, змініть його у відповідному полі налаштувань відеокамери (веб-інтерфейсу).


У разі виникнення будь-яких проблем з налаштуванням RTSP-потоку, зверніться до відповідного розділу.

У посібнику, що постачається разом із камерою відеоспостереження, не завжди може бути інформація про протокол RTSP, згідно з яким пристрій функціонує. Однак існує велика кількість випадків, коли потрібно використовувати цей протокол, тому виникає потреба впізнавати його адресу.

Власнику системи відеоспостереження може знадобитися знання RTSP-потоку в різних ситуаціях:

  • щоб підключити відеокамеру до сервера хмар;
  • щоб настроїти передачу відеоінформації на інтернет-сайт;
  • щоб програвати відео в потоці програвача на різних пристроях - мобільному телефоні, ноутбуці або планшеті.

Навіщо потрібен протокол RTSP?

Назва протоколу RTSP перекладається управління онлайн-режиме. Таким чином, Real Time Streaming Protocol допомагає налагодити керування потоковим відео онлайн. Цей протокол дуже часто використовується в IP-відеоспостереженні, оскільки там є опис необхідних команд.

RTSP-протокол дозволяє власнику камери стеження вирішувати кілька важливих функцій:

  • транслювати дані за допомогою VLC;
  • транслювати відео на свої ресурси та майданчики;
  • налаштовувати NVR-відеореєстратори;
  • з'єднувати камеру відеоспостереження з віртуальним сховищем;
  • додавати відеокамеру до мобільних програм на базі Android або iOS.

При цьому відкрити RTSP-потік багатьом користувачам систем відеоспостереження не дуже просто і досить важко.

Дізнаємось адресу RTSP камери відеоспостереження

Існує кілька варіантів, які дозволяють дізнатися RTSP потік відеокамери, коли він не вказаний у відповідній інструкції.

Велика кількість IP-відеокамер, які продаються в Росії, мають китайські елементи XMEye. Дані комплектуючі можна побачити навіть у вітчизняних виробників таких камер, як Vesta, HiQ, SVplus та подібних. Камера подібних моделей матиме наступний формат потоку RTSP:

rtsp://192.168.132.32:554/user=admin&password=12345&channel=1&stream=0.cgi

У цій адресі присутні такі складові, як:

  • 192.168.132.32 – безпосередньо IP-адреса пристрою;
  • 554 – порт протоколу (за замовчуванням він має номер 554, але цей параметр можна змінити у налаштуваннях пристрою);
  • admin – логін камери відеоспостереження;
  • 12355 – пароль від логіну користувача.

У тому випадку, коли в IP-відеокамері присутні інші комплектуючі, необхідно буде скористатися одним із двох наведених нижче варіантів.

Перший варіант – найспрощеніший. Щоб дізнатися RTSP-потік з камери відеоспостереження, зверніться до виробника або постачальника цього пристрою. На запит вони зможуть надати формат потрібного потоку, причому цю послугу можуть надати навіть китайські продавці – з фабрик з Китаю або сайту AliExpress.

Другий варіант – використовувати спеціалізоване програмне забезпечення. Цей спосіб зможе виручити в тому випадку, коли власник системи відеоспостереження не має можливостей або бажання запросити адресу RTSP-потоку у постачальника. Тоді можна буде зробити це власноруч за допомогою софту.

Для початку потрібно буде завантажити програму під назвою One Device Manager. Після встановлення цей софт допоможе дізнатися RTSP-адресу.

Як правило, більшість відеокамер має підтримку onvif-протоколу, тому при експлуатації програмного забезпечення труднощів виникнути не повинно. Важливий нюанс – для правильної роботи необхідно під'єднати ноутбук або комп'ютер, куди буде встановлена ​​програма, а також сам IP-пристрій до однієї локальної мережі.

У мережі можна знайти цілі списки, де містяться адреси RTSP-потоків, оскільки ці дані залежать від того, який бренд випускає камеру відеоспостереження.

Як відкрити RTSP-потік у відеокамері?

Коли адреса RTSP-потоку стає відома власнику системи стеження, вона може отримувати відеоінформацію з IP-камери. Щоб відкрити трансляцію потокового відео, необхідно буде виконати наступний перелік кроків:

  • встановити для відеокамери постійну IP-адресу та замовити її у постачальника інтернету;
  • перекинути на RTSP-порт локальні запити, що надходять із відеокамери;
  • пройти перевірку працездатності.

Статичну адресу можна налаштувати за допомогою програми IP Hunter або ж зв'язатися з провайдером і попросити її забезпечити як додаткову опцію постійну адресу IP. Після цього потрібно налаштувати переадресацію та прокинути порти на RTSP-порт з локальних портів відеокамери. Потім можна переходити до перевірки потоку.

Щоб зрозуміти, чи має RTSP-посилання працездатність, можна відкрити VLC-плеєр і зробити там перевірку. Для цього в головному меню плеєра потрібно натиснути на категорію Медіа і вибрати пункт Відкрити URL. Далі потрібно перейти на вкладку «Мережа» віконця «Джерело» та вказати своє посилання.

Вирішення задачі онлайн-мовлення з IP-камери, взагалі кажучи, не потребує застосування WebRTC. Камера сама є сервером, має IP-адресу і може бути підключена безпосередньо до маршрутизатора для роздачі відео-контенту. То навіщо застосовувати технологію WebRTC?

На це є як мінімум дві причини:

1. У міру збільшення числа глядачів Ethernet-трансляції все більше відчуватиметься спочатку нестача товщини каналу, а потім і ресурсів самої камери.

2. Як згадувалося вище, IP камера є сервером. Але якими протоколами вона зможе віддати відео браузеру десктопу? Мобільний пристрій? Швидше за все це буде HTTP стрімінг, де відео кадри або JPEG зображення передаються через HTTP. HTTP стрімінг, як відомо, не зовсім підходить для потокового відео реального часу, хоча добре зарекомендував себе в on-Demand відео, де інтерактивність потоку і затримка не особливо важливі. Справді, якщо ви дивитеся фільм, затримка відео в кілька секунд не зробить його гірше, якщо тільки ви не дивитеся цей фільм одночасно з кимось. "О ні! Джек убив її! - пише Еліс у чаті Бобу спойлер за 10 секунд до трагічної розв'язки”.

Або це буде RTSP/RTP і H.264, у разі у браузері має бути встановлений плагін відеоплеєра, такий як VLC чи QuickTime. Такий плагін забиратиме і програватиме відео, як і сам плеєр. Але ж нам потрібен справжній браузерний стрімінг без встановлення додаткових милиць/плагінів.

Для початку посніфаємо IP камеру щоб дізнатися, що саме відправляє цей девайс у бік браузера. Як піддослідний буде камера D-Link DCS 7010L:

Докладніше про встановлення та налаштування камери ви зможете прочитати нижче, а тут ми просто подивимося, що вона використовує для відео стримінгу. При попаданні в адмінку камери через web-інтерфейс спостерігаємо приблизно таку картинку (пардонте за пейзаж):

Картинка відкривається у всіх браузерах і рівномірно підлагоджує приблизно раз на секунду. З огляду на те, що і камера і лаптоп, на якому ми дивимося потік підключені до одного маршрутизатора, все має бути плавно і красиво, але це не так. Схоже на HTTP. Запускаємо Wireshark щоб підтвердити свої припущення:

Тут бачимо послідовність TCP фрагментів завдовжки 1514 байт

І завершальний HTTP 200 OK із довжиною прийнятого JPEG:

Такий стрімінг нам не потрібний. Чи не плавний, смикає HTTP запити. Скільки таких запитів за секунду витримає камера? Є підстави вважати, що на 10 глядачах і раніше камера благополучно загнеться або почне страшно глючити і видавати слайди.

Якщо заглянути в HTML сторінки адмінки камери, побачимо такий цікавий код:

If(browser_IE) DW(""); else ( if(mpMode == 1) var RTSPName = g_RTSPName1; else if(mpMode == 2) var RTSPName = g_RTSPName2; else if(mpMode == 3) var RTSPName = g_RTSPName3; var o=""; (g_isIPv6) //because ipv6 support rtsp.var host = g_netip;else var host = g_host;o+=""; o+=""; o+=""; o+=""; o+=""; o+="//alert(o); DW(o); )

RTSP/RTP - це те, що потрібно для правильного відтворення відео. Але чи це буде працювати у браузері? – Ні. А ось якщо встановити плагін QuickTime – все працюватиме. Але ми робимо чисто-браузерний стрімінг.

Тут можна згадати ще Flash Player, який може через відповідний сервер типу Wowza отримувати потік RTMP, сконвертований з RTSP, RTP, H.264. Але Flash Player, як відомо теж браузерний плагін, хоча незрівнянно популярніший за VLC або QuickTime.

В даному випадку, ми протестуємо той же RTSP/RTP re-streaming, але як програючий пристрій буде використовуватися WebRTC-сумісний браузер без будь-яких додаткових плаунів браузерів і інших милиць. Ми налаштуємо сервер-ретранслятор, який забере потік IP-камери і віддасть його в Інтернет довільній кількості користувачів, що використовують браузери з підтримкою WebRTC.

Підключення IP-камери

Як уже згадувалося вище, для тестування було обрано просту IP-камера D-Link DCS-7010L. Ключовим критерієм вибору тут була підтримка пристроєм протоколу RTSP, оскільки саме за ним наш сервер забиратиме відеопотік із камери.

Камеру підключаємо до маршрутизатора патч-кордом, що йде в комплекті. Після увімкнення живлення та підключення до маршрутизатора, камера взяла IP-адресу по DHCP, у нашому випадку це була 192.168.1.34 (Якщо зайти в налаштування маршрутизатора, ви побачите, що підключено пристрій DCS 7010L – це вона і є). Саме час протестувати камеру.

Відкриваємо вказану IP-адресу в браузері 192.168.1.34, щоб потрапити до веб-інтерфейсу адміністратора камери. За промовчанням пароль відсутній.

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

Налаштування камери

Спочатку в налаштуваннях камери ми відключаємо автентифікацію – в рамках тестування віддаватимемо потік усім, хто попросить. Для цього в веб-інтерфейсі камери заходимо до налаштувань Setup – Networkта виставляємо значення опції Authentication в Disable.

Там же перевіряємо значення порту протоколу RTSP, за замовчуванням він дорівнює 554. Формат відео визначається використовується профілем. У камері їх можна задати до трьох штук, ми скористаємося першим live1.sdp – за замовчуванням він налаштований на використання H.264 для відео та G.711 для аудіо. Змінити налаштування за потреби можна в розділі Setup – Audio and Video.

Тепер можна перевірити роботу камери через RTSP. Відкриваємо VLC Player (можна будь-який інший, що підтримує RTSP - QuickTime, Windows Media Player, RealPlayer та ін.) та в діалозі Open URL задаємо RTSP адресу камери: rtsp://192.168.1.34/live1.sdp

Що ж, все працює, як і має бути. Камера справно відтворює відеопотік у програвачі через протокол RTSP.

До речі, потік відтворюється досить плавно та без артефактів. Чекаємо на те саме і від WebRTC.

Встановлення сервера

Отже, камеру встановлено, протестовано з десктопними плеєрами і готово до мовлення через сервер. За допомогою whatismyip.com визначаємо зовнішню IP-адресу камери. У нашому випадку це було 178.51.142.223. Залишилося сказати роутеру, щоб при зверненні RTSP на порт 554 вхідні запити передавалися на IP-камеру.

Забиваємо відповідні налаштування в маршрутизатор.

…і перевіряємо зовнішню IP адресу та RTSP порт за допомогою telnet:

Telnet 178.51.142.223 554

Переконавшись, що у цьому порту йде відповідь, приступаємо до встановлення WebRTC сервера.

За хостинг відповідатиме віртуальний сервер на Centos 64 bit на Amazon EC2.
Щоб не мати проблем із продуктивністю, вибрали m3.medium інстанс з одним VCPU:

Так, так, є ще Linode та DigitalOcean, але в даному випадку захотілося поамазонити.
Забігаючи вперед, напишу, що в панелі управління Amazon EC2 потрібно додати кілька правил (прокинути порти), без яких приклад не працюватиме. Це порти для WebRTC(SRTP, RTCP, ICE) трафіку та порти для RTSP/RTP трафіку. Якщо пробуватимете, у правилах Amazon має бути щось схоже для вхідного трафіку:

З DigitalOcean все буде простіше, достатньо відкрити ці порти на firewall або заглушити останній. За останнім досвідом експлуатації інстансів DO, там поки що видають статичну IP адресу і не морочаться з NAT-ами, а значить і прокидання портів, як у випадку Амазона, не потрібне.

Як серверне ПЗ, що ретранслює RTSP/RTP потік в WebRTC будемо використовувати WebRTC Media & Broadcasting Server від Flashphoner. Стрімінг сервер дуже схожий на Wowza, яка вміє віддавати RTSP/RTP потік на Flash. Єдина відмінність у тому, що цей потік буде відданий на WebRTC, а не на Flash. Тобто. між браузером і сервером пройде чесний DTLS, встановиться сесія SRTP і потік, закодований в VP8 піде глядачеві.

Для встановлення нам знадобиться SSH-доступ.

Під спойлером – детальний опис виконаних команд

1. Завантажили інсталяційний архів сервера:
$wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. Розгорнули:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Встановили:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
У процесі установки ввели зовнішню IP адресу сервера: 54.186.112.111 і внутрішню 172.31.20.65 (тобто Private IP).
4. Запустили сервер:
$service webcallserver start
5. Перевірили логи:
$tail - f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. Переконалися, що сервер стартував і готовий до роботи:
$ps aux | grep Flashphoner
7. Встановили та запустили apache:
$yum install httpd
$service httpd start
8. Завантажили web-файли та розташували їх у стандартній папці апача /var/www/html
cd /var/www/html
$wget github.com/flashphoner/flashphoner_client/archive/wcs_media_client.zip
$unzip webrtc_media_client.zip
9. Вписали IP адресу сервера в конфіг flashphoner.xml:
10. Зупинили firewall.
$service iptables stop

За ідеєю, замість пункту 10 правильно було б задати всі необхідні порти та правила firewall, але для цілей тестування вирішили просто відключити брендмауер.

Налаштування сервера

Нагадаємо, що структура нашої WebRTC трансляції така:

Встановлення основних елементів цієї діаграми ми вже зробили, залишилося налагодити «стрілочки» взаємодій.

Зв'язок між браузером та WebRTC сервером забезпечує web-клієнт, який є на гітхабі:. Набір JS, CSS та HTML файлів просто закидається в /var/www/htmlна етапі установки (див. вище під спойлер пункт 9).

Взаємодія браузера та сервера налаштовується у конфігураційному файлі XML flashphoner.xml. Туди потрібно вписати IP-адресу сервера, щоб web-клієнт зміг підключатися до WebRTC серверу за HTML5 Websockets (пункт 9 вище).

Налаштування сервера на цьому закінчується, можна перевірити його роботу:

Відкриваємо сторінку web-клієнта index.html у браузері (для цього на той же сервер Амазон було встановлено апач командою yum -y install httpd):

54.186.112.111/wcs_media_client/?id=rtsp://webrtc-ipcam.ddns.net/live1.sdp

Тут webrtc-ipcam.ddns.net- це безкоштовний домен, отриманий через динамічний сервер DNS noip.com , який посилається на нашу зовнішню IP адресу. Маршрутизатору ми сказали перенаправляти RTSP запити на 192.168.1.34 відповідно до правил трансляції мережевих адрес NAT (також див. вище).
Параметр id=rtsp://webrtc-ipcam.ddns.net/live1.sdpзадає URL-адресу потоку для відтворення. WebRTC сервер запросить потоки з камери, обробить їх і віддасть браузеру на відтворення WebRTC. Можливо, ваш роутер підтримує DDNS. Якщо ні, то така підтримка має сама IP камера:

А так підтримка DDNS виглядає у самому роутері:

Тепер можна приступити до тестування та оцінити результати.

Тестування

Після відкриття посилання в браузері йде підключення до WebRTC сервера, який надсилає запит до IP-камери отримання відеопотоку. Весь процес триває кілька секунд.

Саме тоді встановлюється з'єднання браузера з сервером по вебсокетам, далі сервер запитує IP камеру по RTSP, отримує потік H.264 по RTP і транскодує їх у VP8 / SRTP - який у результаті відтворює WebRTC- браузер.

У нижній частині відео відображається URL-відео потоку, який можна скопіювати та відкрити для перегляду з іншого браузера або таба.

Переконуємось що це дійсно WebRTC.

Раптом нас обдурили, і відео з IP камери знову йде по HTTP? Не будемо безглуздо бачити картинку, а перевіримо, що за трафік ми отримуємо насправді. Звичайно ж знову запускаємо Wireshark та консоль налагодження у Chrome. У консолі Chrome браузера можемо спостерігати наступне:

На цей раз нічого не миготить і не видно жодних картинок, що передаються HTTP. Все, що ми бачимо цього разу - це Websocket фрейми і більшість з них відносяться до типів ping/pong для підтримки Websocket-сесії. Цікаві фрейми: connect, prepareRtspSession та onReadyToPlay - саме в такому порядку здійснюється установка підключення до сервера: спочатку коннект по Websocket, а потім запит потоку на відтворення.

А ось що показує chrome://webrtc-internals

За свідченнями графіків, ми маємо бітрейт із IP камери 1Mbps. Вихідний трафік теж є, швидше за все, це RTCP і ICE пакети. RTT до Amazon сервера складає близько 300 мілісекунд.

Тепер завітаємо до Wireshark, там чітко видно UDP трафік з IP адреси сервера. На зображенні нижче пакети по 1468 байт. Це і є WebRTC. Точніше SRTP пакети несуть VP8 відео кадри, які ми можемо спостерігати на екрані браузера. Крім цього проскакують STUN запити (найнижній пакет на картинці) - це WebRTC ICE дбайливо перевіряє з'єднання.

Варто також відзначити порівняно малу затримку (пінг до дата-центру становив близько 250 мс) відтворення відео. WebRTC працює по SRTP/UDP, а це як не крути найшвидший спосіб доставки пакетів, на відміну від HTTP, RTMP та інших TCP-подібних методів стрімінгу. Тобто. затримка, видима оком, повинна становити RTT + час буферизації, декодування та відтворення браузером. Візуально в даному випадку так і є - око майже не бачить затримки, вона менше 500 мілісекунд.

Наступний тест – підключення інших глядачів. Вдалося відкрити 10 вікон Chrome і кожне з них показувало картинку. При цьому сам Chrome почав трохи тупити. При відкритті 11-го вікна іншому комп'ютері, відтворення залишалося плавним.

Про WebRTC на мобільних пристроях

Як відомо, WebRTC підтримують Chrome та Firefox браузери на платформі Android.
Перевіримо, чи буде там відображатися наша трансляція:

На картинці HTC телефон, Firefox браузері відображається відео з камери. Відмінностей у плавності відтворення від робочого столу немає.

Висновок

В результаті нам вдалося запустити WebRTC онлайн-трансляцію з IP-камери на кілька браузерів із мінімальними зусиллями. Не знадобилося ні танців з бубном, ні rocket-science – лише базові знання Linux та SSH-консолі.

Якість трансляції була на прийнятному рівні, а затримка відтворення була непомітною на око.

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

Чому ми не бачимо повсюдного впровадження WebRTC?

Головне гальмо, мабуть, брак кодеків. WebRTC спільноті та вендорам слід було б зробити зусилля і ввести в WebRTC кодек H.264. Проти VP8 сказати нічого, але навіщо відмовлятися від мільйонів сумісних девайсів та ПЗ, які працюють з H.264? Патенти, такі патенти...

На другому місці не повна підтримка в браузерах. C IE і Safari, наприклад, питання залишається відкритим і там доведеться переходити на інший тип стрімінгу або використовувати плагін типу webrtc4all.

Так що в майбутньому сподіваємося побачити більш цікаві рішення, в яких не потрібен буде транскодинг і конвертація потоків і більшість браузерів зможуть відігравати потоки з різних пристроїв вже безпосередньо.

Часто виникає запитання: Як підключити IP камеру до NVR якщо її немає в списку сумісності?

Існує два варіанти ONVIF та RTSP

Почнемо з протоколу ONVIF (Open Network Video Interface Forum)

ONVIF це загальноприйнятий протокол для спільної роботи IP камер, відеореєстраторів NVR, програмного забезпечення, якщо всі пристрої різних виробників. ONVIF можна порівняти з англійською для міжнародного спілкування людей.

Переконайтеся, що пристрої, що підключаються, мають підтримку ONVIF, на деяких пристроях ONVIF може бути вимкнений за замовчуванням.
Або може бути відключена авторизація за ONVIF це означає, що логін/пароль буде завжди за умовчанням
незалежно від логіну/паролю для WEB

Також варто зазначити, що деякі пристрої використовуютьокремий порт для роботи за протоколом ONVIF

У деяких випадках ONVIF пароль може відрізнятись від пароля для WEB доступу.

Що доступне при підключенні ONVIF ?

Виявлення пристроїв

Передача відеоданих

Прийом та передача аудіо даних

Керування поворотними камерами (PTZ)

Відеоаналітика (наприклад, виявлення руху)

Ці параметри залежать від сумісності версій ONVIF. У деяких випадках частина параметрів недоступна або працює некоректно.

До і з використанням ONVIF


У реєстраторах SNR та Dahua протокол ONVIF знаходиться на вкладці Remote Device, рядок Manufacturer

Виберіть канал, до якого буде підключено пристрій

З вкладки Manufacturer виберіть ONVIF

Вкажіть ip адресапристрої

RTSPпорт залишається за умовчанням

Камери використовують ONVIF порт 8080
(з 2017 року, на нових моделях ONVIF порт змінено на 80 для серії Альфа, Світу)
Камери OMNY Baseвикористовують ONVIF порт 80, у реєстраторі він вказується як HTTP порт

Ім'я

Парольвідповідно до параметрів пристрою

Remote channelза промовчанням 1. Якщо пристрій багатоканальний, вказується номер каналу.

Decoder Buffer— буферизація відео потоку із зазначенням значення часу

Server typeтут є вибір TCP,UDP Schedule

TCP- встановлює з'єднання між відправником та одержувачем, стежить за тим, щоб усі дані дійшли до адресата без змін та в потрібній послідовності, також регулює швидкість передачі.

На відміну від TCP, UDPне встановлює попереднього з'єднання, а натомість просто починає передавати дані. UDP не стежить, щоб дані були отримані, і не дублює їх у разі втрат або помилок.

UDP менш надійний, ніж TCP. Але з іншого боку, він забезпечує швидшу передачу потоків завдяки відсутності повторення передачі втрачених пакетів

Schedule- Автоматичне визначення типу.

Так виглядають підключені пристрої у Dahua

Зелений статус означає, що реєстратор та камера з'єднані успішно

Червоний статус означає, що є проблеми підключення. Наприклад, порт підключення неправильний.

Другий спосіб підключення це RTSP(Real Time Streaming Protocol)

RTSPпотоковий протокол реального часу, в якому описані команди для управління потоком відео.

За допомогою цих команд відбувається трансляція відеопотоку від джерела до одержувача

наприклад, від IP-камери до відеореєстратора або сервера.

Що доступне при підключенні через RTSP?

Передача відеоданих

Прийом та передача аудіо даних

Перевагацього протоколу передачі у цьому, що не вимагає сумісності за версіями.

на сьогоднішній день RTSP підтримують практично всі IP камери та NVR

Недолікипротоколу в тому, що крім передачі відео та аудіо даних більше нічого не доступно.

Розберемо приклад підключення камеридо і з використанням RTSP

RTSPзнаходиться на вкладці Remote Device, рядок Manufacturer, у реєстраторі SNR та Дахуа він представлений якGeneral

Виберіть канал, до якого буде підключено пристрій

URL Addr- тут вводимо рядок запиту, яким камера віддає Основний RTSP потік з високим дозволом.

Extra URL - тут вводимо рядок запиту, за яким камера віддає додатковий RTSP потік з низьким дозволом.

Приклад запиту:

rtsp://172.16.31.61/1 основний потік

rtsp://172.16.31.61/2 додатковий потік

Навіщо потрібний додатковий потік?

На локальному моніторі, підключеному до реєстратора в мульти-картинці, реєстратор використовує додатковий потік для економії ресурсів. Наприклад у дрібних картинках по 16 вікон зовсім не обов'язково декодувати Full HD роздільну здатність, досить D1. Ну а якщо Ви відкрили 1/4/8 вікон, у цьому випадку декодується основний потік з високою роздільною здатністю.

Ім'явідповідно до параметрів пристрою

Парольвідповідно до параметрів пристрою

Decoder Bufferбуферизація відео потоку із зазначенням значення часу

Server type- TCP, UDP, Schedule (аналогічно протоколу ONVIF)

Ця стаття відповідає на найпоширеніші питання, такі як:

чи сумісна IP камера з реєстратором NVR?

А якщо сумісна то як підключити!