В случае сложностей с настройкой или эксплуатацией продукции, ознакомьтесь с часто задаваемыми вопросами и ответами на них.
Как получить подарочную лицензию REVISOR VMS?
Для получения подарочной лицензии Revisor VMS следуйте инструкции. Скачать инструкцию .
У меня 1.3 Мп IP-камера RedLine. Пытаюсь установить ActiveX, но возникает ошибка "HTTP 404 — не найдено", что делать?
В 1.3 Мп видеокамерах модуль ActiveX не встроен, его необходимо установить с диска, который идет в комплекте или загрузить по ссылке
Для камер 4MP:
rtsp://admin:123456@IP-адрес:554/ch01/0 - основной поток
rtsp://admin:123456@IP-адрес:554/ch01/1 - доп поток
rtsp://admin:123456@IP-адрес:554/streaming/mjpeg - поток mjpeg
Для камер 1,3MP и 2 MP
rtsp://admin:123456@IP-адрес:554/streaming/video0 - основной поток
rtsp://admin:123456@IP-адрес:554/streaming/video1 - доп поток
Какое ПО подходит для мобильных устройств?
Какие порты необходимы для работы через сеть?
80 - web интерфейс
554- rtsp (видео) поток
4900 - моб. порт
9988 - Для клиенских подключений к 4MP IP-камерам
Что делать если не работает звук на регистраторе или в стороннем ПО?
Для передачи звука необходимо в настройках во вкладке СЕТЬ - RTSP поток, активировать передачу аудио.
Объем занимаемого пространства зависит от выбранного качества записи и частоты движения (при записи по детекции). Для расчёта архива можно использовать ПО Disk calculator .
Как найти IP камеру в локальной сети?
Установите ПО и запустите от имени администратора. В появившемся окне Вы увидите список оборудования, подключенного в локальную сеть.
Для изменения настроек сети необходимо выбрать оборудование в верхнем поле и в нижнем поле указать настройки сети (IP-адрес, маску, шлюз), ввести имя пользователя, пароль и нажать кнопку Modify. В дальнейшем для подключения необходимо использовать заданный IP
.
Для 1,3MP и 2 MP IP-камер реккомендуется использовать
Как добавить 1.3 MP IP камеру в CVMS?
Если камера находится в локальной сети, то в режиме просмотра, в меню Устройства (слева) нажать правой кнопкой и выбрать "Быстрый поиск", затем выбрать нужную камеру и указать пароль.
Если подключение будет осуществляться через интернет, то в режиме просмотра, в меню Устройства (слева) нажать правой кнопкой и выбрать "Добавить устройство" и ввести данные для подключения, НЕОБХОДИМО УКАЗЫВАТЬ ПОРТ TCP (по умолчанию 1115)
По некоторым данным, на сегодняшний день, в мире установлены сотни миллионов 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 сервера с помощью групп транскодирования. Сервер создает несколько групп по битрейту, например две:
- 200 Kbps
- 1 Mbps
Третий вариант предполагает полный отказ от транскодинга на стороне сервера и использование уже подготовленных видеопотоков в различных разрешениях и битрейтах. В этом случае камера настраивается на отдачу двух или трех потоков с разными разрешениями и битрейтами, а зрители переключаются между этими потоками в зависимости от своей пропускной способности.
В этом случае транскодинговая нагрузка на сервер уходит и смещается на саму камеру, т.к. камера теперь вынуждена кодировать два и более потоков вместо одного.
В результате мы рассмотрели три варианта подстройки под полосу пропускания зрителей. Если предположить, что одна транскодинг-сессия забирает 1 ядро сервера, то получаются следующая таблица нагрузки на CPU:
Из таблицы видно, что мы можем сместить транскодинговую нагрузку на камеру либо отдать транскодирование на сервер. Варианты 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 .
После установки необходимо переключить сервер в режим 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 адрес.
Если у вас дружелюбный 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 |
Мы сделали несколько снимков чтобы зафиксировать значения задержки.
Комфортный просмотр видеотрансляции или можно настроить с помощью программных мультимедийных плееров на вашем персональном компьютере. Сегодня мы рассмотрим, как настроить RTSP поток для сетевого оборудования Dahua Technology в одном из самых популярных плееров VLC Media Player.
RTSP (Real Time Streaming Protocol – потоковый протокол реального времени) – протокол, позволяющий пользователю удаленно воспроизводить поток мультимедийных данных (аудио и видео) с помощью гиперссылки и мультимедийного плеера (в нашем случае VLC Media Player).
Если у вас возникла необходимость настройки видеопотока, воспользуйтесь следующими шагами:
- Прежде всего, необходимо скачать и установить VLC Media Player, который доступен на официальном сайте в свободном доступе.
- Кликните на пункт меню Media (Медиа) – Open Network Stream (Открыть URL).
- Введите сетевой адрес RTSP в советующую строку.
- Нажмите кнопку воспроизведения, когда видеоизображение появится на экране.
Расшифровка ссылки RTSP
Пример:
rtsp://:@:/cam/realmonitor?channel=&subtype=
Где :
rtsp://admin:[email protected]:554/cam/realmonitor?channel=1&subtype=1
IP-видеокамеры Dahua Technology поддерживают протоколы передачи данных TCP и UDP. Если порт 554 был изменен, измените его в соответствующем поле настроек видеокамеры (веб-интерфейса).
В случае возникновения каких-либо проблем с настройкой RTSP-потока, обращайтесь в соответствующий раздел.
Как проверить возможность трансляции RTSP потока с IP камеры в различных Web-браузерах
Проверим отображение RTSP-видеопотока в браузерах Chrome, Firefox, Safari на десктопах с ОС Windows, Mac OS X, Linux и мобильных устройствах под управлением Android и iOS
Проверяем RTSP-поток в VLC
Чтобы быстро убедиться в том, что RTSP-поток доступен и отдает видео, открываем его в VLC-плеере . Если поток воспроизводится корректно, переходим к тестированию web-интерфейса. RTSP URL вы можете получить в панели управления IP-камерой или использовать какой-нибудь публично доступный RTSP-видеопоток, например этот: rtsp://b1.dnsdojo.com:1935/live/sys3.stream
Тестируем RTSP-WebRTC поток в браузерах Google Chrome и Mozilla Firefox
Убеждаемся в том, что тот же самый RTSP-поток воспроизводится на обычной HTML-странице в браузерах Chrome и Firefox.
1. Загружаем демо-интерфейс по адресу , меню ‘Demo / Streaming Min’. Это минимальный HTML5 web-интерфейс, который использует WebRTC-технологию для отображения RTSP-видеопотока в браузерах Chrome и Firefox.
2. Устанавливаем соединение с Web Call Server
3. Вписываем адрес RTSP камеры и запускаем воспроизведение потока:
В результате успешно проверили воспроизведение RTSP-потока в браузере Google Chrome. Аналогичный тест можно провести с браузерами Firefox и Opera на тех десктопных и мобильных платформах, которые поддерживают технологию WebRTC в браузерах.
Тестируем RTSP-Websocket поток в браузере Safari под iOS и Mac OS X
Браузеры на iOS устройствах не поддерживают технологию WebRTC. По этой причине используется отдельный плеер ‘WS Player Min’, который забирает поток по протоколу Websocket и воспроизводит в HTML5-Canvas элементе браузера.
1. Также как и в случае с Chrome нужно открыть страницу демо-интерфеса, но выбрать другой пункт меню:
2. После этого установить соединение с Web Call Server
3. Вписать заранее известный адрес RTSP трансляции и воспроизвести видеопоток:
Таким образом выше продемонстрированна возможность просматривать переконвертированный с помощью Web Call Server RTSP трафик на большинстве из распространенных Web браузеров, в том числе на наиболее популярных мобильных платформах.
Следующим шагом будет добавление HTML5 RTSP-плеера на ваш собственный веб-сайт. Процесс добавления подробно описан в соседнем разделе Внедрение
Видеоролики с описанием процесса тестирования RTSP-WebRTC и RTSP-Websocket плеера
RTSP-WebRTC плеер для Chrome и Firefox
RTSP-Websocket плеер для iOS Safari
Загрузить Web Call Server 5
Системные требования : Linux x86_64, 1 core CPU, 2 Gb RAM, Java
Установка:
- wget https://сайт/download-wcs5.2-server.tar.gz
- Распаковать и установить с помощью скрипта "install.sh"
- Запустить сервер с помощью команды "service webcallserver start"
- Открыть веб-интерфейс https://host:8444 и активировать вашу лицензию
Если вы используете серверы Amazon EC2, то скачивать ничего не нужно.
Удаление вирусов