Протокол RTSP

RTSP (Real Time Streaming Protocol, или, по-русски, потоковый протокол реального времени) – это прикладной протокол, в котором описаны команды для управления видеопотоком. С помощью этих команд мы можем «приказать» камере или серверу, например, начать трансляцию видеопотока. Пример запроса на начало воспроизведения выглядит так: PLAY rtsp://192.168.0.200/h264 RTSP/1.0

То есть RTSP – это просто набор команд для управления видеопотоком. Проведем эксперимент. Для этого нам понадобится IP-камера с поддержкой RTSP протокола и ее RTSP адрес. Этот адрес выглядит примерно так rtsp:///mpeg. Его можно узнать из руководства по эксплуатации камеры либо из описания API. Для удобства мы приведем RTSP адреса для ряда популярных камер в таблице. После того, как мы узнали RTSP-адрес камеры, открываем стандартный проигрыватель, поддерживающий RTSP. Это может быть одна из следующих программ: Windows Media Player, QuickTime, Media Player Classic, VLC media player, RealPlayer, MPlayer. Мы выбрали QuickTime. Открываем меню «Файл > Открыть URL» и вводим наш RTSP адрес. После чего QuickTime подключится к камере и воспроизведет «живое видео». Устройства записи, работающие в системах IP-видеонаблюдения, получают видео от камер либо с помощью протокола HTTP – то есть также, как мы скачиваем JPEG-картинки с сайтов, либо в виде потока через RTSP – то есть также как мы получили его с помощью стандартного проигрывателя в последнем примере. В настройках IP-камер потоковый вариант передачи данных может обозначаться как RTSP over TCP, RTSP over UDP либо просто RTP. Итак, RTSP – это набор команд для управления потоком. Но что означают остальные аббревиатуры: TCP, UDP, RTP? TCP, UDP и RTP - это транспортные механизмы (протоколы), которые собственно и передают видео.

Протокол TCP

Допустим, мы выбрали метод RSTP over TCP и хотим начать передачу видеопотока. Что будет происходить на уровне транспортных механизмов? Предварительно с помощью нескольких команд будет установлено соединение между отправителем и получателем. После этого начнется передача видеоданных. При этом механизмы TCP

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

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

надежен, чем TCP. Но с другой стороны, он обеспечивает более быструю передачу потоков благодаря отсутствию механизма повторения передачи потерянных пакетов. Различие в протоколах TCP и UTP можно иллюстрировать следующим примером. Встречаются два друга. Вариант TCP:

Иван: «Привет! Поболтаем?» (устанавливается соединение)
Семен: «Привет! Давай!» (устанавливается соединение)
Иван: «Я вчера был в магазине. Ты понял?» (передача данных)
Семен: «Да!» (подтверждение)
Иван: «Там разгружали новое оборудование. Ты понял?» (передача данных)
Семен: «Нет» (подтверждение)
Иван: «Там разгружали новое оборудование. Ты понял?» (повторная передача)
Семен: «Да!» (подтверждение)
Иван: «Завтра я там еще раз буду. Ты понял?» (передача данных)
Семен: «Да!» (подтверждение)
Вариант UDP
Иван: «Привет! Я вчера был в магазине» (передача данных)
Иван: «Там разгружали новое оборудование» (передача данных)
Иван: «Завтра я там еще раз буду» (передача данных)
Иван: «Могу узнать для тебя цены» (передача данных)
Иван: «Они обещали скидки при хороших объемах» (передача данных)
Иван: «Если хочешь, позвони – поедем вместе» (передача данных)
Семен: «Да, позвоню» (передача данных)

Вы также можете увидеть различие в протоколах, поставив следующий эксперимент: попробуйте перевести камеру в режим RTSP over TCP и помашите рукой перед объективом - на экране монитора вы увидите задержку. А теперь проведите этот же тест в режиме RTSP over UDP. Задержка будет меньше. На время задержки влияют несколько факторов: формат сжатия, мощность компьютера, протокол передачи и особенности программного обеспечения, участвующего в декодировании видео.

RTP (Real-time Transport Protocol), или по-русски транспортный протокол реального времени. Этот протокол специально создан для передачи реалтайм трафика. Он позволяет следить за синхронизацией передаваемых данных, корректировать последовательность доставки пакетов и потому более других подходит для передачи видео- и аудиоданных. В общем случае для передачи видеопотока предпочтительнее использовать либо RTP либо UDP. Работа через TCP оправдана лишь если нам приходится работать с проблемными сетями, так как протокол TCP сможет корректировать ошибки и сбои, возникающие при передаче данных.

По некоторым данным, на сегодняшний день, в мире установлены сотни миллионов 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 ), то на этом канале будут большие потери и, как следствие фризы видео или сильные артефакты.

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

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

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

Второй вариант заключается в уменьшении нагрузки на CPU сервера с помощью групп транскодирования. Сервер создает несколько групп по битрейту, например две:

• 200 Kbps
• 1 Mbps

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

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

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

В результате мы рассмотрели три варианта подстройки под полосу пропускания зрителей. Если предположить, что одна транскодинг-сессия забирает 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

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

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

Как проверить возможность трансляции 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

Установка:

1. wget https://сайт/download-wcs5.2-server.tar.gz
2. Распаковать и установить с помощью скрипта "install.sh"
3. Запустить сервер с помощью команды "service webcallserver start"
4. Открыть веб-интерфейс https://host:8444 и активировать вашу лицензию

Если вы используете серверы Amazon EC2, то скачивать ничего не нужно.

Комфортный просмотр видеотрансляции или можно настроить с помощью программных мультимедийных плееров на вашем персональном компьютере. Сегодня мы рассмотрим, как настроить 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. Данным значением можно пренебречь.

: номер канала. Нумерация начинается с 1.

: тип потока. Значение главного потока равно 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». Далее потребуется перейти на вкладку «Сеть» окошка «Источник» и указать свою ссылку.