Rtsp поток с видеорегистратора как настроить

Часто задаваемые вопросы (ЧаВо)

Если вы не нашли ответ на свой вопрос, то обратитесь в техническую поддержку help@rvi-cctv.ru

Добавление устройств по протоколам Private, Onvif и RTSP в регистраторы

Разберем на примере регистратора ipn16/2-16p-4k и камерой ipc44 v.2:

Зайдите в web интерфейс регистратора — «Настройка» — «Добавить» и нажмите кнопку «Вручную».

1. В открывшемся окне выберите «Производитель» (протокол управления) — Private. В поле «IP» введите ip адрес камеры, в данном примере у камеры ip адрес 192.168.12.24. «TCP порт» выставляется автоматически. Для протокола «Private» по умолчанию он имеет значение 37777, но на камере он может быть изменен. Удостоверьтесь, что TCP порт задан корректно. Заполните поля «Имя» и «Пароль» — это логин и пароль, которые существуют в учетных записях камеры. Нажмите кнопку «Ок». Камера добавится в список добавленных устройств.

* — Посмотреть, какой у вас выставлен TCP порт на камере можно в web интерфейсе камеры в настройках сети — вкладка «Соединение».

2. При добавлении по протоколу Onvif. Порядок действий аналогичный описанному выше. Меняется только производитель на «Onvif» и порт. По умолчанию порт у протокола Onvif — 80. Посмотреть какой порт задан на камере можно так же в web интерфейсе камеры в настройках сети.

На большинстве камер RVI с прошивками от 2018 года появилась возможность создания пользователя Onvif, который необходим для добавления устройства в регистраторы. Более подробно об этом можно почитать в статье » Добавление камер в регистратор серии 2NR со встроенным PoE «

3. При добавлении по протоколу RTSP необходимо построить RTSP ссылку по которой регистратор будет получать видеопоток с камеры. С примерами RTSP ссылок можно ознакомиться в отдельной статье на сайте.

Пример с моделью регистратора 2NR16240-p и камерой ipc44 v.2:
Платформа данной модели камеры отличается от платформы регистратора и подключить эту камеру к регистратору по протоколу Private не удастся. Для подключения возможно использовать протоколы Onvif и RTSP.

1. Добавление камеры по протоколу ONVIF.
Для добавления камеры зайдите в web интерфейс регистратора — «Настройки» — «Управление камерами» и нажмите «Добавить».

В открывшемся окне заполните поле «Адрес IP камеры», выберите протокол управления Onvif, порт управления по умолчанию выставляется в значение 80 (на камере он может отличаться, как было описано выше), а так же укажите пользователя и пароль, которые существуют в учетных записях камеры.

2. Добавление камеры по протоколу RTSP.
Перед добавление камеры по протоколу RTSP необходимо предварительно настроить один из пользовательских протоколов (по нему и будет производиться добавление). Зайдите в web интерфейс регистратора — «Настройки» — «Управление камерами» и нажмите кнопку «Пользовательский протокол»

В открывшемся окне необходимо выбрать пользовательский протокол, который необходимо отредактировать (по умолчанию во всех протоколах RTSP ссылки не заполнены).
Для примера заполним «Пользовательский протокол 1», у которого имя протокола «Custom 1».
Задайте порт RTSP (по умолчанию имеет значение 554, но может отличаться). Для основного потока RTSP ссылка опять же будет
rtsp://admin:admin123@192.168.12.24:554/RVi/1/1,
после перейдите во вкладку «Дополнительный поток» и аналогично заполните поля, для дополнительного потока RTSP ссылка будет
rtsp://admin:admin123@192.168.12.24:554/RVi/1/2.
После заполнения всех полей нажмите «Ок».

* — При необходимости для других пользовательских протоколов можно задать другие форматы RTSP ссылок, это будет полезно в том случае, когда вы работаете с оборудование разных производителей.

Нажмите кнопку «Добавить». В открывшемся окне задайте IP-адрес камеры в поле «Адрес IP камеры», выберите протокол «Custom 1» (его вы редактировали в примере выше), заполните поля «Пользователь», «Пароль» и «Подтвердить» — это логин и пароль, которые существуют в учетных записях камеры, нажмите кнопку «Ок».

Источник

7 способов отобразить видео с RTSP IP-камеры на веб-странице и 2 в мобильном приложении

В этой статье покажем 7 технологически разных способов отображения видеопотока с IP-камеры с поддержкой RTSP на web-странице браузера.

Браузеры, как правило, не поддерживают RTSP, поэтому поток будет конвертироваться для браузера через промежуточный сервер.

Способ 1 — RTMP

RTMP протокол браузеры не поддерживают, но его поддерживает старый добрый Flash Player, который работает неплохо, хоть и не во всех браузерах, и может отобразить видеопоток.

Код плеера в этом случае будет построен на Action Script 3 и выглядеть примерно так:

rtmp://192.168.88.59/live — это адрес промежуточного сервера, который заберет RTSP видеопоток с камеры и конвертирует его в RTMP

rtsp://192.168.88.5/live.sdp — это RTSP адрес самой камеры.

Немного избыточный вариант кода плеера на Flex и AS3 доступен здесь.

Выглядит это так:

Способ 2 — RTMP с оберткой HTML5

Желающих кодить на Action Script 3 все меньше. Специально для этого придуман способ с HTML5 оберткой, которая позволяет управлять RTMP-плеером из JavaScript. В этом случае флэшка подгружается на HTML-страницу только для того чтобы отобразить картинку и выдать в динамики звук.

Полный код плеера находится здесь. А выглядит это так:

Способ 3 — RTMFP

Протокол RTMFP также работает внутри флэш плеера. Разница с RTMP в том, что RTMFP работает поверх протокола UDP и тем самым является более пригодным для получения трансляции с низкой задержкой.

Код плеера на AS3 в этом случае полностью идентичен используемому в RTMP, добавлена одна буква F в строке протокола подключения к серверу.

Для порядка дадим скриншот с RTMFP

Способ 4 — RTMFP c оберткой HTML5

Этот способ идентичен пункту 2, с той разницей, что мы при инициализации в JavaScript устанавливаем RTMFP протокол для использования в нижележащей флэшке (swf-объекте).

Способ 5 — WebRTC

В данном случае Flash не используется совсем и видеопоток проигрывается средствами самого браузера, без использования сторонних плагинов. Это работает и в Android Chrome и Android Firefox — мобильных браузерах, где Flash не установлен. WebRTC дает самую низкую задержку — менее 0.5 секунды.

Код плеера тот же:

Автоматически определяется поддержка WebRTC, и если поддерживается то поток играет по WebRTC.

Способ 6 — Websockets

WebRTC и Flash не покрывают все браузеры и платформы. Например, в браузере iOS Safari эти технологии не поддерживаются.

На iOS Safari можно доставить видеопоток по транспорту Websocket (TCP соединению между браузером и сервером). В этот туннель можно завернуть сконвертированный с RTSP видеопоток. После того, как бинарные данные придут их можно декодировать с помощью JavaScript и отрисовать на Canvas HTML5-элементе.

Именно этим занимается Websocket — плеер при работе в браузере iOS Safari, а его код снаружи выглядит также:

Это чем-то похоже на подход с флэшкой, когда под HTML5 лежит swf-элемент. В данном случае, под HTML5-страницей лежит не swf-объект, а JavaScript-приложение, которое тянет данные по вебсокетам, декодирует и отрисовывает на Canvas в нескольких потоках.

Так выглядит RTSP поток на Canvas в браузере iOS Safari

Способ 7 — HLS

При конвертации RTSP в HLS, видеопоток разбивается на сегменты, которые благополучно скачиваются с сервера и отображаются в HLS-плеере.

В качестве HLS-плеера мы используем video.js. Код плеера можно скачать здесь.

Как выглядит плеер:

Способ 8 — Android приложение, WebRTC

Приложение забирает поток с сервера по WebRTC. Задача сервера в этом случае — сконвертировать RTSP в WebRTC и скормить мобильному приложению.

Java-код плеера для Android находится здесь и выглядит так:

Тестовое мобильное приложение плеера можно установить из Google Play, а исходники приложения скачать здесь.

Так выглядит воспроизведение RTSP потока по WebRTC на планшете Asus под Android:

Способ 9 — iOS приложение, WebRTC

Приложение также как и в случае Android забирает поток с сервера по WebRTC.

Скачать исходный код плеера для iOS можно здесь.

А из App Store можно установить тестовое приложение, которое использует показанные выше куски кода. Его работа с RTSP-потоком выглядит так:

Результаты

Подведем итоги и объединим полученные результаты в табличку:

Способ отображения	Применение	Задержка
1	RTMP	Там, где важно использование legacy — флэш клиента, Flex или Adobe Air	medium
2	RTMP + HTML5	В браузерах IE, Edge, Mac Safari, если там установлен Flash Player	medium
3	RTMFP	Там, где важно использование legacy — флэш клиента, Flex или Adobe Air и важна низкая задержка	low
4	RTMFP + HTML5	В браузерах IE, Edge, Mac Safari, если там установлен Flash Player и важна низкая задержка.	low
5	WebRTC	В браузерах Chrome, Firefox, Opera на десктопах и мобильных браузерах под Android, где важна real-time задержка.	real-time
6	Websocket	В браузерах, где нет Flash и WebRTC, но нужна средняя или низкая задержка.	medium
7	HLS	Во всех браузерах. Где не важна задержка.	high
8	Android app, WebRTC	В нативных мобильных приложениях под Android, где требуется real-time задержка.	real-time
9	iOS app, WebRTC	В нативных мобильных приложениях под iOS, где требуется real-time задержка.	real-time

Для тестирования мы использовали сервер Web Call Server 5, который конвертирует RTSP поток для раздачи в 9 перечисленных направлениях.

Ссылки

Web Call Server 5 — сервер для раздачи RTSP потока
Flash Streaming — пример swf приложения, проигрывающего потоки по RTMP и RTMFP. Способы 1 и 3.
Source — исходный код swf приложения на Flex / AS3.

Player — пример web-приложения, которое воспроизводит RTSP поток по RTMP, RTMFP, WebRTC, Websocket. Способы 2,4,5,6.
Source — исходный код веб-плеера.

HLS плеер — пример web-плеера, играющего HLS. Способ 7.
Source — исходный код HLS плеера.

Android плеер WebRTC — пример мобильного приложения, которое играет поток по WebRTC. Способ 8.
Source — исходный код мобильного приложения.

iOS плеер WebRTC — пример мобильного приложения, которое играет WebRTC поток. Способ 9.
Source — исходный код мобильного приложения.

Источник

Трансляция RTSP в WEB. Конвертация в HLS. Коробочное решение

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

Оговорюсь сразу: в процессе эксплуатации данного решения обнаружилась возможность шаринга видео-архива средствами SAMBA. Эта возможность показалась очень удобной лично для меня и я решил реализовать её в данном контексте. Конечно, у кого-то может возникнуть вопрос: «Есть ведь Линия и зачем всё прочее нужно?» — в нашем случае это решение оказалось слишком дорогое. А еще они до сих пор считают в долларах. Итак, что имеется:

• Корпоративная сеть на базе Mikrotik средствами обычного VPN
• Несколько ССTV состоящих из самых разных камер и видео-регистратора
• Linux машина с развернутым SAMBA-AD-DC и WEB сервером в центральном офисе

Стоит ли напоминать, что всё это дело у нас конвертируется из RTSP в HLS? Ставлю на Linux хост Shinobi по этой инструкции. В установке нету ничего сложного, требуется только установить git, некоторые зависимости и запустить скрипт установки. Технически та же Линия, только бесплатно. Возможно на первое время хватит. Интерфейс только кажется удобнее, в остальном тоже самое. После установки и запуска открываем localhost:8080/super логинимся как admin@shinobi.video с паролем admin и создаём основную запись для доступа к мониторингу.

Параметры хранения информации, используемые по-умолчанию, мне не подошли. Кроме того, в процессе эксплуатации я долго искал эти настройки, но срочность вынудила попросту отключить cron.js (sudo pm2 stop cron) и средствами уже Linux’a чистить каталоги видео-архива.

Number of Days to keep Videos — количество дней на хранение видеозаписей.
Number of Days to keep Events — количество дней на хранение событий (входы, смены пароля и прочее).
Number of Days to keep Logs — количество дней на хранение системных сообщений: сбои, ошибки, инициализация.

Все эти параметры задаются индивидуально для каждого пользователя, очень удобно. Но кроме этого существует еще и API. Его средствами можно получить все потоки конкретного монитора (монитор — это набор потоков для трансляции) и представить каждый из них по отдельности в виде онлайн трансляции на web-странице. Для начала необходимо добавить в мониторинг информацию о потоках с камер видео-наблюдения.

Mode — режим трансляции: Record — запись, Watch only — только просмотр.
Name — название видео-потока
Storage location — место хранения архива, если в Mode у вас выставлен Record
Full URL Path — ссылка на сам rtsp поток. Для netsurveillance как правило такая ссылка: rtsp://IP:554/user=USER&password=PASSWORD&channel=CHANNELNUMBER&stream=1.sdp?real_stream—rtp-caching=100

Информация о потреблении ресурсов отображаемая в Shinobi сильно разнится с тем, что показывает htop. В web-интерфейсе я постоянно вижу наполовину забитую память, но вот загрузка процессора, кстати, вполне соответствует тому, что видно из консоли.

Насколько было известно, так же есть возможность использовать системный GPU для конвертации потока. Но так как у нас он не установлен, то убедиться в этом не было возможности. Всё происходит средствами CPU. У нас задействована конвертация 17 потоков 3 из которых записываются локально. Приведу здесь информацию о нашем процессоре:

Если нужно только подключить онлайн трансляцию на веб страничке, то необходимо сперва добавить API ключ пользователю, чей монитор нас интересует. Полное руководство по API находится на официальном сайте приложения. Сверху помещаем курсор на email пользователя, кликаем, выбираем пункт API.

Основной параметр для нас — это Allowed IPs (разрешенные IP). У меня доступ открыт только для локальной сети, но если вы планируете стримить свои потоки в глобальный Интеренет, то необходимо указать 0.0.0.0/0 и пробросить порт Shinobi наружу.

Технически, Shinobi позволяет очень гибко организовать трансляцию RTSP потока, который поддерживается даже самыми простыми видео-регистраторами. Всё зависит от вашей фантазии и потребностей. Что касается технических возможностей: в случае если вы используете аналоговые камеры, вам 100% понадобится какой-никакой, но видео-регистратор с интерфейсом RJ-45. Всё куда проще, если вы используете IP камеры: них уже есть сетевой интерфейс и видео-поток генерируется аппаратными средствами самой камеры. Но стоят они на порядок дороже чем AHD камеры. Зато цифровые камеры выигрывают по таким параметрам как скорость передачи, и, что более значительно (если речь идет о расследовании происшествий) — качество изображения, не говоря уже удобстве развёртывания и реорганизации.

Информацию о веб-потоках можно получиться простым GET запросом, результат получаем в формате JSON, который легко преобразовать в данные. Пример простого скрипта на PHP:

Для некоторых камер у меня указан режим Recording. В данном случае, помимо конвертирования потока ведется еще и запись с RTSP на локальный жесткий диск. Если в параметрах Recording указанно Default то запись будет храниться в папке ./Shinobi/videos/[MinitorID]/[CameraID]. У меня же некоторые папки с основного монитора доступны по сети и монтируются средствами GPO для определенной группы как сетевые диски.

Зачем это сделано? Простая особенность логистики: бывает, что большая машина загружается товаром и уезжает в другой город, там разгружается уже покупателем, который может заявить что чего-то не хватает. А бывает, что и в своих магазинах уже не могут чего-то досчитаться. Поэтому для склада ведется отдельная запись с некоторых камер уже в mp4 формате. Это может сэкономить кучу времени на разборе полётов.

Источник