Rtsp авторизация – Настройка видеорегистратора для прямого вещания RTSP канала прямой трансляции видео изображения | Дропшиппинг

Содержание

Формы запроса видеопотока (RTSP, HTTP) с авторизацией

IP-домофоны
Запрос видеопотока
rtsp://admin:password@<IP адрес>:<порт>/av0_<номер_потока>	admin — логин, password — пароль на логин <IP адрес> — IP адрес камеры <порт> — RTSP-порт (по умолчанию 554) <номер_потока> — число 0 или 1 (0 — основной, 1 — дополнительный)
rtsp://<IP адрес>:<порт>/av<номер канала>_<номер_потока> &user=admin&password=password
Запрос изображения
http://<IP адрес>/cgi-bin/images_cgi?channel=<номер потока>&user=admin&pwd=password	<IP адрес> — IP адрес домофона <номер_потока> — число 0 или 1 (0 – основной поток, 1 – альтернативный) admin — логин, password — пароль на логин
B серия
В17xxхх, В27xxхх, B1001, B1012, B1014, B1018
rtsp://admin:password@<IP адрес>:<порт>/av<номер канала>_<номер_потока>	admin — логин, password — пароль на логин <IP адрес> — IP адрес камеры <порт> — RTSP-порт (по умолчанию 554) <номер_потока> — число 0 или 1 (0 — основной, 1 — дополнительный)
BD серия
Запрос первого потока видео в формате H.264
rtsp://admin:password@<IP адрес>:<порт>/h364	admin — логин, password — пароль на логин <IP адрес> – IP адрес камеры <порт> – RTSP-порт камеры (по умолчанию 554)
rtsp://admin:password@<IP адрес>:<порт>/video.h364
Запрос 2, 3 или 4 потока видео в формате H.264
rtsp://admin:password@<IP адрес>:<порт>/h364_<номер_потока>	admin — логин, password — пароль на логин <IP адрес> – IP адрес камеры <порт> – RTSP-порт камеры (по умолчанию 554) <номер_потока> – число от 2 до 4
Запрос изображения
http://admin:password@<IP адрес>/cgi -bin/jpg/image.cgi (только при включённом MJPEG потоке!)	admin — логин, password — пароль на логин <IP адрес> – IP адрес камеры
http://admin:password@<IP адрес>/jpg/image.jpg	admin — логин, password — пароль на логин <IP адрес> – IP адрес камеры
N серия
Запрос видео (N37210, N132xx, N1xx, N3xx, N5xx, N6xx)
http://admin:password@<IP адрес>/jpg/image.jpg	admin — логин, password — пароль на логин <IP адрес> – IP адрес камеры

Как подключить IP камеру по Onvif или RTSP? — Телекоммуникационное оборудование

Часто возникает вопрос: Как подключить ip камеру к NVR если ее нет в списке совместимости?

Существует два варианта ONVIF и RTSP

Начнем с протокола ONVIF (Open Network Video Interface Forum)

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

Убедитесь, что подключаемые устройства имеют поддержку ONVIF, на некоторых устройствах ONVIF может быть выключен по умолчанию.
Либо может быть отключена авторизация по ONVIF это значит, что логин/пароль будет всегда по умолчанию
независимо от логина/пароля для WEB

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

В некоторых случаях ONVIF пароль может отличаться от пароля для WEB доступа.

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

-Обнаружение устройств

-Передача видеоданных

-Прием и передача аудио данных

-Управление поворотными камерами (PTZ)

-видеоаналитика (например обнаружение движения)

Эти параметры зависят от совместимости версий протокола ONVIF. В некоторых случаях часть параметров недоступна, или работает некорректно.

Разберем пример подключения камеры OMNY PRO к видеорегистратору SNR и Dahua с использованием ONVIF

В регистраторах SNR и Dahua протокол ONVIF находится на вкладке Remote Device, строка Manufacturer

Выберите канал к которому будет подключено устройство

Из вкладки Manufacturer выберите ONVIF

Укажите ip адрес устройства

RTSP порт остается по умолчанию

Камеры OMNY PRO используют ONVIF порт 8080, в регистраторе он указывается как HTTP порт
(с 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

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

Разберем пример подключения камеры OMNY PRO к видеорегистратору SNR и Dahua с использованием 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 ?

А если совместима то как подключить!?

RTSP ссылки | Частые вопросы

RTSP-ссылки

Основная и универсальная ссылка для IP камер, NVR и DVR:
rtsp://admin:[email protected]:554/ISAPI/Streaming/Channels/101
где:
rtsp — тип используемого протокола
admin — имя учетной записи
12345 – пароль используемой учетной записи
192.168.200.11 — IP-адрес камеры
554 — RTSP порт камеры (по умолчанию 554, может быть изменен в настройках)
101 — это 1 камера 1 поток
201 — это 2 камера 1 поток
102 — это 1 камера 2 поток

IP каналы HD-TVI регистраторов
7204 — 501 601;
7208 — 901 1001;
7X16 — 1701 1801 и т.д

Для вызывных панелей:

rtsp://admin:[email protected]:554/Streaming/Channels/101

Устаревшие ссылки:
rtsp://admin:12345@IP-камеры:554/mpeg4/ch01/main/av_stream
получение потока с первого канала
rtsp://admin:12345@IP-камеры:554/mjpeg/ch2/sub/av_stream
получение потока mjpeg со второго потока. прошивка должна поддерживать mjpeg на втором
потоке.

MJPEG и фото:
Для получения MJPEG-потока по HTTP (суб-поток камеры должен быть настроен как mjpeg)

Перевести в MJPEG можно только суб-поток камеры.

http://admin:пароль@IP-камеры:порт-http/streaming/channels/102/httpPreview

получить JPEG-снимок основного потока камеры:
http://admin:passwd@ip-cam/ISAPI/Streaming/channels/101/picture?snapShotImageType=JPEG

Формы запроса видеопотока (RTSP, HTTP) без авторизации

IP-домофоны DS03M(P)
rtsp://<IP адрес>:<порт>/av0_<номер_потока>	<IP адрес> – IP адрес домофона <порт> – RTSP-порт камеры (по умолчанию 554) <номер_потока> – число 0 или 1 (0 – основной поток, 1 – альтернативный)
B серия
B10xx, B2.9xx, B1720
rtsp://<IP адрес>:<порт>	<порт> – RTSP-порт камеры (по умолчанию 554) <IP адрес> – IP адрес камеры
rtsp://<IP адрес>:<порт>/av0_<номер_потока>	<номер_потока> – число 0 или 1 (0 – основной поток, 1 – альтернативный)
В1710хх, В2710хх, В2720хх
rtsp://<IP адрес>:<порт>/av0_<номер_потока>	<номер_потока> – число 0 или 1 (0 – основной поток, 1 – альтернативный)
B1001, B1012, B1014, B1018
rtsp://<IP адрес>:<порт>/av<номер_канала>_<номер_потока>	<номер_канала> – число от 0 до 3, определяющее канал, с которого будет выдан видеопоток (0 – 1-й канал, 1 – 2-й канал и т.д.) <номер_потока> – число 0 или 1 (0 – основной поток, 1 – альтернативный)
BD серия
Запрос первого потока видео в формате H.264
rtsp://<IP адрес>:<порт>/h364	<порт> – RTSP-порт камеры (по умолчанию 554) <IP адрес> – IP адрес камеры
Запрос 2, 3 или 4 потока видео в формате H.264
rtsp://<IP адрес>:<порт>/h364_<номер_потока>	<порт> – RTSP-порт камеры (по умолчанию 554) <IP адрес> – IP адрес камеры <номер_потока> – число от 2 до 4
Запрос видео в формате MPEG4
rtsp://<IP адрес>:<порт>/mpeg4	<порт> – RTSP-порт камеры (по умолчанию 554) <IP адрес> – IP адрес камеры
Запрос видео в формате MJPEG
rtsp://<IP адрес>:<порт>/jpeg	<порт> – RTSP-порт камеры (по умолчанию 554) <IP адрес> – IP адрес камеры
http://<IP адрес>:<порт>	<порт> – MJPEG-порт к HTTP камеры (по умолчанию 8008) <IP адрес> – IP адрес камеры
Запрос изображения
http://<IP адрес>:<порт>/cgi-bin/jpg/image.cgi	<порт> – HTTP-порт (по умолчанию 80) <IP адрес> – IP адрес камеры
N серия
Запрос видео (N37210, N132xx, N1xx, N3xx, N5xx, N6xx)
rtsp://<IP адрес>:<порт>/video.pro<N>	<порт> – RTSP-порт камеры (по умолчанию 554) <IP адрес> – IP адрес камеры <N> – номер профиля
Запрос видео в формате H.264 (N131xx, N35110)
rtsp://<IP адрес>:<порт>/video.h364	<порт> – RTSP-порт камеры (по умолчанию 554) <IP адрес> – IP адрес камеры
Запрос видео в формате MP4 (N1000, N1250, N131xx, N66xx, N35110)
rtsp://<IP адрес>:<порт>/video.mp4	<порт> – RTSP-порт камеры (по умолчанию 554) <IP адрес> – IP адрес камеры
Запрос видео в формате MJPG (N1000, N1250, N131xx, N66xx, N35110)
rtsp://<IP адрес>:<порт>/video.mjpg	<порт> – RTSP-порт камеры (по умолчанию 554) <IP адрес> – IP адрес камеры
Запрос изображения (N1000, N1250, N131xx, N66xx, N35110)
http://<IP>/jpg/image.jpg	<IP адрес> – IP адрес камеры

RTSP запрос — Телекоммуникационное оборудование

Как получить RTSP поток с IP видеокамер ?
IP камеры и NVR обычно умеет отдавать два типа потока
1.Главный с высоким разрешением (зависит от камеры) Main stream
2. Дополнительный с низким разрешением (D1,CIF,VGA) Sub stream
Ниже приведены примеры.
OMNY PRO: rtsp://<ЛОГИН>:<ПАРОЛЬ>@ip-адрес/<НОМЕР_ПОТОКА> (1- главный, 2- дополнительный)
Пример: rtsp://admin:[email protected]/1 (принимаем главный поток)
OMNY BASE: rtsp://<ЛОГИН>:<ПАРОЛЬ>@ip-Адрес/live/ПОТОК (main, sub или jpeg)
Пример: rtsp://admin:[email protected]/live/main (принимаем главный поток)
Dahua: rtsp://<ЛОГИН>:<ПАРОЛЬ>@ip-адрес:554/cam/realmonitor?channel=1&subtype=<НОМЕР_ПОТОКА>(0- главный, 1-дополнительный)
Пример:rtsp://admin:[email protected]:554/cam/realmonitor?channel=1&subtype=0 (принимаем главный поток)
SNR-CI-D: rtsp://<ЛОГИН>:<ПАРОЛЬ>@ip-адрес:554/cam/realmonitor?channel=1&subtype=<НОМЕР_ПОТОКА>(0- главный, 1-дополнительный)
Пример:rtsp://admin:[email protected]:554/cam/realmonitor?channel=1&subtype=0
SNR-CI-H: rtsp://<ЛОГИН>:<ПАРОЛЬ>@ip-адрес:554/av0_1 (av0_0 главный, av0_1 — дополнительный)
Пример: rtsp://admin:[email protected]:554/av0_0
PICxx : rtsp://<ЛОГИН>:<ПАРОЛЬ>@ip-Адрес/ПОТОК (main — главный, sub — дополнительный)
Пример: rtsp://admin:[email protected]:554/main
PWTxx: rtsp://<ЛОГИН>:<ПАРОЛЬ>@ip-адрес/id=ПОТОК ( 0 — главный, 1 — дополнительный)
Пример: rtsp://admin:[email protected]/id=1

Как получить RTSP поток с NVR ?

OMNY PRO: rtsp://<ЛОГИН>:<ПАРОЛЬ>@ip-адрес/<НОМЕР_КАНАЛА>/НОМЕР ПОТОКА (Поток: 1- главный, 2- дополнительный)
Пример: rtsp://192.168.10.5/2/1 (главный поток с канала № 2)

Dahua: rtsp://<ЛОГИН>:<ПАРОЛЬ>@ip-адрес:554/cam/realmonitor?channel=1&subtype=<НОМЕР_ПОТОКА>(0- главный, 1-дополнительный)
Пример:rtsp://admin:[email protected]:554/cam/realmonitor?channel=6&subtype=0 (главный поток с канала №6)

SNR-NVR rtsp://<ЛОГИН>:<ПАРОЛЬ>@ip-адрес:554/cam/realmonitor?channel=1&subtype=<НОМЕР_ПОТОКА>(0- главный, 1-дополнительный)
Пример:rtsp://admin:[email protected]:554/cam/realmonitor?channel=6&subtype=0 (главный поток с канала №6)
Аналогично для SNR-DVR-D

Что делать если видео нестабильно, большое количество артефактов

Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой / Habr

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

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

Прежде всего давайте устраним возможное недопонимание в терминологии про вебкамеры и IP-камеры.

Вебкамера — это устройство захвата видео, не имеющее собственного процессора и сетевого интерфейса. Вебкамера требует подключения к компьютеру, смартфону, либо другому устройству, имеющему сетевую карту и процессор.

IP-камера — это автономное устройство, имеющее собственную сетевую карту и процессор для сжатия захваченного видео и отправки в сеть. Таким образом, IP-камера представляет собой автономный мини-компьютер, который полноценно соединяется с сетью и не требует подключения к другому устройству, и может напрямую вещать в сеть.

Низкая задержка (low latency) — это достаточно редкое требование для IP-камер и онлайн-трансляций. Необходимость работы с низкой задержкой появляется, например, в том случае, если источник видеопотока активно взаимодействует со зрителями этого потока.

Чаще всего низкая задержка необходима в игровых сценариях использования. В качестве таких примеров можно привести: видео-аукцион в реальном времени, видео-казино с живым дилером, интерактивное онлайн-тв шоу с ведущим, удалённое управление квадрокоптером, и т.д.
Дилер живого интернет-казино за работой.

Обычная RTSP IP камера, как правило жмёт видео в H.264 кодек и может работать в двух режимах транспортировки данных: interleaved и non-interleaved.

Режим interleaved наиболее популярный и удобный, т.к. в этом режиме видео данные передаются по протоколу TCP внутри сетевого подключения к камере. Для того чтобы раздавать с IP-камеры в interleaved нужно всего лишь открыть / пробросить один RTSP-порт камеры (например 554) наружу. Плееру остаётся лишь подключиться к камере по TCP и забрать поток уже внутри этого соединения.

Вторым режимом работы камеры является non-interleaved. В этом случае соединение устанавливается по протоколу RTSP / TCP, а трафик идёт уже отдельно, по протоколу RTP / UDP вне созданного TCP-канала.
Режим non-interleaved более благоприятен для трансляции видео с минимальной задержкой, так как использует протокол RTP / UDP, но в то же время является более проблемным, если плеер расположен за NAT.
При подключении к IP-камере плеера, который находится за NAT, плеер должен знать — какие внешние IP-адреса и порты он может использовать для приема аудио и видео трафика. Эти порты указываются в текстовом SDP-конфиге, который передается камере при установке RTSP-соединения. Если NAT был вскрыт правильно и определены корректные IP-адреса и порты, то все будет работать.

Итак, для того чтобы забрать видео с камеры с минимальной задержкой, нужно использовать non-interleave mode и получать видеотрафик по UDP.

Браузеры не поддерживают стек протоколов RTSP / UDP напрямую, но поддерживают стек протоколов встроенной технологии WebRTC.

Технологии браузера и камеры очень похожи, в частности SRTP это шифрованное RTP. Но для корректной раздачи на браузеры, IP камере бы потребовалась частичная поддержка WebRTC-стека.

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

Сервер забирает поток с IP-камеры на себя по RTP / UDP и отдаёт подключившимся браузерам по WebRTC.

Технология WebRTC работает по протоколу UDP и тем самым обеспечивает низкую задержку по направлению Сервер > Браузер. IP-камера также работает по протоколу RTP / UDP и обеспечивает низкую задержку по направлению Камера > Сервер.

Камера может отдать ограниченное количество потоков, в силу ограниченных ресурсов и полосы пропускания. Использование промежуточного сервера позволяет масштабировать трансляцию с IP камеры на большое число зрителей.

С другой стороны, при использовании сервера, включаются две коммуникационных ноги:
1) Между зрителями и сервером
2) Между сервером и камерой
Такая топология имеет ряд «особенностей» или «подводных камней». Перечислим их ниже.

Подводный камень #1 — Кодеки

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

Например, если камера отдает 720p видеопоток в H.264, а подключается Chrome-браузер на смартфоне Android с поддержкой только VP8.

При включении транскодинга, для каждой из подключенных IP-камер должна быть создана транскодинг-сессия, которая декодирует H.264 и кодирует в VP8. В этом случае 16 ядерный двухпроцессорный сервер сможет обслужить только 10-15 IP камер, из примерного расчета 1 камера на физическое ядро.

Поэтому если серверные мощности не позволяют транскодировать планируемое количество камер, то транскодинга нужно избегать. Например обслуживать только браузеры с поддержкой H.264, а остальным предлагать использовать нативное мобильное приложение для iOS или Android, где есть поддержка кодека H.264.

Как вариант для обхода транскодинга в мобильном браузере, можно использовать HLS. Но стриминг по HTTP совсем не обладает низкой задержкой и в настоящий момент не может быть использован для интерактивных трансляций.

Подводный камень #2 — Битрейт камеры и потери

UDP протокол помогает справиться с задержкой, но допускает потери видеопакетов. Поэтому несмотря на низкую задержку, при больших потерях в сети между камерой и сервером, картинка может быть испорчена.
Для того чтобы исключить потери, нужно убедиться, что генерируемый камерой видеопоток имеет битрейт, который помещается в выделенную полосу между камерой и сервером.

Подводный камень #3 — Битрейт зрителей и потери

Каждый подключившийся к серверу зритель трансляции также имеет определенную пропускную способность на Download.

Если IP-камера отправляет поток, превышающий возможности канала зрителя (например камера отправляет 1 Mbps, а зритель может принять только 500 Kbps), то на этом канале будут большие потери и, как следствие фризы видео или сильные артефакты.

В этом случае есть три варианта:

Транскодировать видеопоток индивидуально под каждого зрителя под требуемый битрейт.
Транскодировать потоки не для каждого подключившегося, а для группы группы зрителей.
Подготовить потоки с камеры заранее в нескольких разрешениях и битрейтах.

Первый вариант с транскодингом под каждого зрителя не подходит, так как израсходует ресурсы CPU уже при 10-15 подключившихся зрителей. Хотя нужно отметить, что именно этот вариант дает максимальную гибкость при максимальной загрузке CPU. Т.е. это идеальный вариант например в том случае, если вы транслируете потоки всего на 10 географически распределенных человек, каждый из них получает динамический битрейт и каждому из них нужна минимальная задержка.
Второй вариант заключается в уменьшении нагрузки на CPU сервера с помощью групп транскодирования. Сервер создает несколько групп по битрейту, например две:
В случае, если зрителю не хватает пропускной полосы, он переключается в ту группу, в которой он сможет комфортно получать видеопоток. Таким образом, количество транскодинг-сессий не равно количеству зрителей как в первом случае, а является фиксированным числом, например 2, если групп транскодинга две.
Третий вариант предполагает полный отказ от транскодинга на стороне сервера и использование уже подготовленных видеопотоков в различных разрешениях и битрейтах. В этом случае камера настраивается на отдачу двух или трех потоков с разными разрешениями и битрейтами, а зрители переключаются между этими потоками в зависимости от своей пропускной способности.

В этом случае транскодинговая нагрузка на сервер уходит и смещается на саму камеру, т.к. камера теперь вынуждена кодировать два и более потоков вместо одного.

В результате мы рассмотрели три варианта подстройки под полосу пропускания зрителей. Если предположить, что одна транскодинг-сессия забирает 1 ядро сервера, то получаются следующая таблица нагрузки на CPU:

	Способ подстройки	Количество ядер на сервере
1	Транскодировать видеопоток под каждого зрителя под требуемый битрейт	N — количество зрителей
2	Транскодировать видеопотоки по группам пользователям	G — количество групп зрителей
3	Подготовить потоки с камеры заранее в нескольких разрешениях и битрейтах	0

Из таблицы видно, что мы можем сместить транскодинговую нагрузку на камеру либо отдать транскодирование на сервер. Варианты 2 и 3 при этом выглядят наиболее оптимальными.

Тестирование RTSP как WebRTC

Пришла пора провести несколько тестов для выявления действительной картины происходящего. Возьмем реальную IP-камеру и проведем тестирование с целью измерения задержки при трансляции.

Для тестирования возьмем древнюю IP-камеру D-link DCS-2103 с поддержкой RTSP и кодеков H.264 и G.711.

Так как камера долго пролежала в шкафу с другими полезными девайсами и проводами, пришлось отправить ее в Reset, нажав и подержав кнопку на задней стороне камеры 10 секунд.

После подключения к сети, на камере загорелась зеленая лампочка и роутер увидел еще одно устройство в локальной сети с IP адресом 192.168.1.37.

Заходим в веб-интерфейс камеры и выставляем кодеки и разрешение для тестирования:

Далее заходим в сетевые настройки и узнаем RTSP адрес камеры. В данном случае RTSP-адрес live1.sdp, т.е. Камера доступна по адресу rtsp://192.168.1.37/live1.sdp
Доступность камеры легко проверить с помощью VLC плеера. Media — Open Network Stream.

Мы убедились, что камера работает и отдает видео по RTSP.

В качестве сервера для тестирования будем использовать Web Call Server 5. Это стриминг сервер с поддержкой RTSP и WebRTC протоколов. Он будет подключаться к IP-камере по RTSP и забирать видеопоток. Далее раздавать поток по WebRTC.

Вы можете установить Web Call Server на свой хост либо запустить готовый инстанс Amazon EC2.

После установки необходимо переключить сервер в режим RTSP non-interleaved, который мы обсуждали выше. Это можно сделать добавлением настройки

rtsp_interleaved_mode=false

Эта настройка добавляется в конфиг flashphoner.properties и требует перезагрузки сервера:

service webcallserver restart

Таким образом, у нас есть сервер, который работает по схеме non-interleaved, принимает пакеты от IP-камеры по UDP, и далее раздаёт по WebRTC (UDP).
Тестовый сервер находится на VPS-сервере, расположенном в датацентре Франкфурта, имеет 2 ядра и 2 гигабайта RAM.

Камера находится в локальной сети по адресу 192.168.1.37.

Поэтому первое что мы должны сделать — это пробросить порт 554 на адрес 192.168.1.37 для входящих TCP / RTSP соединений, чтобы сервер мог установить подключение к нашей IP-камере. Для этого в настройках роутера добавляем всего одно правило:

Правило говорит роутеру перенаправлять весь входящий на порт 554 трафик, на 37 — IP адрес.

Далее осталось узнать свой внешний IP-адрес. Это можно сделать за 5-15 секунд, погуглив по слову whatismyip

Если у вас дружелюбный NAT и вы знаете внешний IP-адрес, то можно начинать тесты с сервером.

Стандартный демо плеер в браузере Google Chrome выглядит так:

Чтобы начать играть RTSP поток, нужно просто ввести его адрес в поле Stream.
В данном случае адрес потока: rtsp://ip-cam/live1.sdp
Здесь ip-cam это внешний IP адрес вашей камеры. Сервер будет пытаться установить соединение именно по этому адресу.

Тестирование задержек VLC vs WebRTC

После того, как мы настроили IP камеру и протестировали в VLC, настроили сервер и протестировали RTSP поток через сервер с раздачей по WebRTC, мы наконец-то можем сравнить задержки.

Для этого будем использовать таймер, который будет показывать на экране монитора доли секунды. Включаем таймер и воспроизводим видеопоток одновременно на VLC локально и на браузере Firefox через удалённый сервер.

Пинг до сервера 100 ms.
Пинг локально 1 ms.

Первый тест с использованием таймера выглядит так:
На черном фоне расположен исходный таймер, который показывает нулевую задержку. Слева VLC, справа Firefox, получающий WebRTC поток с удаленного сервера.

	Zero	VLC	Firefox, WCS
Time	50.559	49.791	50.238
Latency ms	0	768	321

На этом тесте видим задержку на VLC в два раза больше чем задержку на Firefox + Web Call Server, не смотря на то, что видео в VLC воспроизводится в локальной сети, а видео, которое отображается в Firefox проходит через сервер в датацентре в Германии и возвращается обратно. Такое расхождение может быть вызвано тем, что VLC работает по TCP (interleaved mode) и включает какие-то дополнительные буферы для плавного воспроизведения видео.

Мы сделали несколько снимков чтобы зафиксировать значения задержки:

Результаты измерений выглядят так:

	Metric	Zero	VLC	Firefox, WCS
Test1	Time	50.559	49.791	50.238
Test1	Latency	0	768	321
Test2	Time	50.331	49.565	49.951
Test2	Latency	0	766	380
Test3	Time	23.870	23.101	23.548
Test3	Latency	0	769	322
Average			768	341

Таким образом, средняя задержка при тестировании с VLC в локальной сети составила 768 миллисекунд. В то время, как средняя задержка при проходе видео через удаленный сервер составила 341 миллисекунду, т.е. была в 2 раза ниже при использовании UDP и WebRTC.

Тестирование задержек RTMP vs WebRTC

Проведем похожие тесты с RTMP- плеером через Wowza сервер и одновременный тест с WebRTC-плеером через Web Call Server.

Слева забираем видеопоток с Wowza в RTMP-подключении. Справа забираем поток по WebRTC. Сверху абсолютное время (нулевая задержка).

Тест — 1

Тест — 2
Тест — 3
Тест — 4
Результаты тестирования можно вывести в уже знакомую таблицу:

	Metric	Zero	RTMP	WebRTC
Test1	Time	37.277	35.288	36.836
Test1	Latency	0	1989	441
Test2	Time	02.623	00.382	02.238
Test2	Latency	0	2241	385
Test3	Time	29.119	27.966	28.796
Test3	Latency	0	1153	323
Test4	Time	50.051	48.702	49.664
Test4	Latency		1349	387
Average			1683	384

Таким образом, средняя задержка при воспроизведении RTSP потока в Flash Player по RTMP составила 1683 миллисекунд. Средняя задержка по WebRTC 384 миллисекунды. Т.е. WebRTC оказалась в среднем в 4 раза лучше по задержке.

Ссылки

Технология WebRTC
RTSP — RFC
RTSP interleaved — RFC, 10.12 Embedded (Interleaved) Binary Data
RTMP — спецификация
Web Call Server — WebRTC медиасервер с поддержкой RTSP
VLC — плеер для воспроизведения RTSP

Как узнать RTSP поток с IP камеры

Далеко не всегда в инструкции IP камеры указывается описание RTSP протокола, с которым работает Ваша камера. Тем не менее иногда возникает необходимость воспользоваться RTSP протоколом для подключения IP камеры к облачному серверу, настройки трансляции изображения на сайт или воспроизведения потокового видео в каком-нибудь плеере на Вашем ПК или гаджете.

Рассмотрим все возможные способы, как узнать адрес RTSP IP камеры, если он не представлен в руководстве камеры.

Если Ваша камера собрана из китайских xmeye комплектующих (что часто встречается на российском рынке, в том числе и у российских производителей ip камер HiQ, Vesta, SVplus и др бренды), то формат адреса RTSP камеры будет иметь следующий вид:

rtsp://199.255.20.999:554/user= login&password=pswrd& channel=1&stream=0.cgi

(убрать пробелы)

где

199.255.20.999 – IP адрес Вашей камеры
554 – RTSP порт камеры (можно изменить в настройках камеры)
login – логин пользователя камеры (можно использовать пользователя «admin», но для настройки потокового видео по RTSP протоколу лучше создать специального пользователя в настройках камеры, который будет иметь ограниченные права доступа)
pswrd – пароль пользователя

Если Ваша камера собрана из других комплектующих, то есть два способа, как узнать адрес RTSP потока Вашей камеры.

1 Способ. Самый простой способ – запросить формат адреса RTSP IP камеры у поставщика или продавца камеры. Даже если камера приобретена у китайцев (aliexpress или китайская фабрика), в большинстве случаев продавец предоставляет формат адреса RTSP камеры.

2 Способ. Если Вы не желаете или не имеете возможности связываться с продавцом и хотите узнать RTSP адрес камеры самостоятельно, скачайте и установите программу onvif device manager. Почти все IP камеры поддерживают протокол onvif, поэтому данное ПО с наибольшей вероятностью поможет Вам определить адрес RTSP потока Вашей IP камеры. IP камера и компьютер, на который будет установлено данное ПО, должны быть подключены к одной локальной сети.

RTSP (англ. Real Time Streaming Protocol — потоковый протокол реального времени) –протокол, в котором описаны команды для управления видеопотоком.

3 Способ. Вы можете найти URL адрес RTSP потока Вашей IP камеры в специальной статье — URL адреса RTSP и порты IP камер разных производителей

Читайте также как узнать IP адрес камеры

Дата публикации: 27.02.2018
Автор: Дримерс

Сохранить в соц. сети

Рейтинг статьи

4.6

8 оценок

Оцените статью