Проброс rtsp потока через роутер

База Знаний

Инструменты пользователя

Инструменты сайта

Содержание

Настройка камер видеонаблюдения

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

К сети может быть подключена практически любая IP-камера, способная отдавать изображение в виде потока RTSP (де-факто стандарт в IP камерах), и поддерживающая протокол ONVIF для позиционирования (если камера управляемая). В целом, схема подключения выглядит так:

1. Для начала нужно подключить камеру к локальной сети, присвоив ей статический IP адрес.

Если вы ведете учет адресов в подсети своего роутера, то для вас не составит никакого труда определить и назначить свободный. Если не ведете – зайдите в роутер, в разделе с названием близким к «Локальная сеть» (на разных роутерах по-разному) найдите «DHCP» и посмотрите, какой диапазон адресов выдается по запросам устройств. Возьмите любой адрес, входящий в подсеть адресов роутера, но не входящий в диапазон DHCP . Проверьте, на всякий случай, что этот адрес свободен с помощью команды PING. Если адрес свободен – назначьте его на камеру (как правило, в камерах – настройки/сеть/сетевые реквизиты), предварительно отключив в камере «подключение по DHCP».

2. Посмотрите в камере номер порта RTSP (обычно – 554) и номер порта ONVIF, если камера поворотная. Эти порты в дальнейшем надо будет «прокинуть» за роутер. Найдите в камере (обычно на странице настройки сетевых реквизитов или настройки потока) строку запроса потока RTSP. Обычно это выглядит так: rtsp://логин:пароль@IPадрес:554/ISAPI/Streaming/Channels/101

Вам нужно будет ввести эту строку при проверке в VLC-плеере и в форму подключения в личном кабинете (user.infolink.ru).

Вы можете столкнуться с камерами, в инструкциях которых нет формата RTSP ссылки. Для поиска необходимой ссылки, можно воспользоваться программой Оnvif device manager, которую можно скачать здесь.

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

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

4. Следующим шагом нам надо осуществить «проброс портов камеры за роутер», то есть обеспечить прохождение трафика с определенных портов на внешнем IP адресе роутера, на нужные нам порты подключенной камеры. «Пробросить» надо порт RTSP камеры (обычно – 554), и порт ONVIF, если камера управляемая.

Для первой камеры – все просто, используйте стандартный порт 554 для RTSP и, например, 10080 для ONVIF (если он вам нужен). Но если камер больше, чем одна, нужно помнить правило: «Внутри сети устройства сидят на разных IP адресах, снаружи – на одном адресе, но на разных портах». То есть порт RTSP второй камеры, даже если он у нее, тоже 554-й, должен быть проброшен на другой порт роутера. Как его определить? Корректно- выбрать из числа свободных. Поскольку вы вряд ли, когда нибудь столкнётесь с сетевыми службами, занимающими эти порты, можно использовать порты 555,556,557,558…

5. Теперь, когда мы определились с портами, начнем настройку роутера.

Рассмотрим примеры настройки некоторых моделей роутеров:

Порядок настройки проброса портов на примере роутера Mercusys AC1200:

Порядок настройки проброса портов на примере роутера Dlink DIR645:

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

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

Теперь, чтобы камера заработала в системе, надо настроить ее параметры через «Личный кабинет». Заходим в личный кабинет, нажимаем на «Видеонаблюдение».

В разделе «Новая камера видеонаблюдения» нажимаем кнопку «Подключить».

На открывшейся странице вводим:

Выбираем технологию трансляции.

Если камера неуправляемая – выбирайте технологию HLS. Эта технология обеспечивает наиболее стабильную трансляцию изображения с камеры, поддерживается всеми браузерами и мобильными устройствами, однако имеет недостаток в виде задержки между реальным событием и трансляцией, которая составляет три промежутка между опорными кадрами (I- кадрами). В зависимости от того, как настроена Ваша камера это может составлять от 2 до 15 секунд.

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

После того, как вы заполнили все поля, нажимаем кнопку «Добавить камеру». Нас возвращает на страницу «Видеонаблюдение», где мы видим изменившееся название камеры и появление у нее кнопок «Трансляция» и «Архив» и сверху надпись: «Изменения приняты».

В это время идут внутренние процессы на серверах компании, обычно занимающие несколько минут. При нажатии на кнопку «Трансляция» можно видеть:

Это значит камера еще не добавилась на серверах. Далее, через какое-то время, при нажатии увидите:

Это означает что камера добавлена, но поток с нее пока не транслируется. И, наконец, через какое-то время Вы увидите само изображение с Вашей камеры:

Это значит, что процесс завершен, и камера полностью подключена.

Читайте также:  Zyxel keenetic lite ndms

Перейдя обратно на вкладку «Видеонаблюдение», Вы можете подключить запись (архивацию) изображения с камеры.

Как пользоваться нашим сервисом «Видеонаблюдение»

Управлять камерами вы можете:

Источник

Проброс rtsp потока через роутер

Всем привет. Помогите пожалуйста расколдовать загадку. Я в RouterOS не спец, и вообще от сетевых технологий далёк, но постараюсь максимально внять и понять тех, кто откликнится на помощь.

Имеем китайскую IP камеру TH38E5 с последней прошивкой, подключена к MikroTik hAP lite classic (RB941-2nD) с привязкой к 192.168.88.12, провайдер выдаёт статический белый IP, предположим 99.99.99.99. В настройках камеры доступ по 80 порту и 554. Плюс какой-то порт для PTZ, но это не интересует.
В Микротике сделал проброс портов, в том числе и для RTSP 554й порт.
Но, по rtsp ни одна прога не может подключится к камере и получить видеопоток ни в локалке ни из внешки((
Веб морда камеры доступна отовсюду.

Вот всё что в Firewall:

1) надеюсь в роутере Вы отключили веб-морду самого роутера на 80-м порту?
(IP-Services, www) ?
1.1) Управляеть надо/очень желательно только через утилиту Winbox

2) В Файрволе, в закладке NAT = рекомендую пробросы портов переместить выше, относительно правил
маскарада (ибо внутри роутера, пробросы обрабатываются раньше маскарада)
2.1) У Вас два правила маскарада, и то правило, где нет указания исходящей сети,
оно более глобально, и вдобавок оно стоит первее, поэтому оно и выполняется,
а второе правило — холостое, срабатывать оно не будет успевать.
Так что тут Вы перемудрили. Надо оставить одно.

3) НО всё это мелочи, главные ошибки тех, кто пытается сделать пробросы:

а) устройство, на которое мы(Вы) делаете проброс — оно должно быть правильно
настроено, а именно: у камеры Вашей должен быть обязательно задан шлюз,
и шлюз этот должен быть — локальный адрес роутера. Так что проверьте камеру
тоже, кроме адреса, маски, ШЛЮЗ должен быть обязательно задан (камера
должна знать куда ей «отвечать» на пришедшие запросы).

б) и ещё самая большая ошибка — при созданий правил проброса, проверять работу пробросов
надо с другого физического канала. То есть мы как бы приоткрыли дверь снаружи,
а многие начинающие делают пробросы, но лезут изнутри в эти же двери, и конечно же ошибка.
Самый простой способ, не выходя из дому: включаете на смартфоне режим ТОЧКИ доступа,
подключаете ноутбук через эту точку на смартфоне и уже работая в Интернете через смартфон,
и соответственно через сотового оператора, доходите до своего роутера снаружи и пытаетесь
зайти на камеру по открытому порту.
Для тестов на 5-10 минут (даже если нет на смартфоне включенного трафика), думаю
такой тест всё равно можно сделать. и сильно отразиться на балансе телефона.

И вот самые простые работающие правила пробросов (как пример Вам, ибо у Вас там тоже много лишнего)

Источник

Добавление RTSP-камеры¶

Некоторые камеры можно подключить, передав в систему прямую ссылку на RTSP-трансляцию. Для этого у камеры должны быть следующие характеристики:

  • видеокодек — H.264,
  • аудиокодек — AAC или G.711,
  • размер изображения — не более 1920х1080,
  • битрейт — не более 1,5 мбит/сек.

Что нужно сделать, чтобы подключить камеру по RTSP¶

Сформировать RTSP-ссылку для данной модели камеры.

Формат ссылок для разных производителей и моделей может отличаться. Информацию о формате ссылки можно найти на сайте производителя камеры. Для камер Hikvision и HiWatch ссылка имеет формат rtsp://admin:password@IP_address:554/Streaming/Channels/101 , где

  • rtsp — тип используемого протокола,
  • admin — логин для входа на камеру,
  • password — пароль для камеры,
  • IP_address — внешний IP-адрес роутера, к которому подключены камеры,
  • 554 — внешний порт подключения (внешний порт может быть любой свободный).

Нажать кнопку «RTSP-камера».

Ввести ссылку в соответствующее поле.

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

Пример ссылок для подключения трех камер:

  • rtsp://admin:password@IP_address:554/Streaming/Channels/101
  • rtsp://admin:password@IP_address:555/Streaming/Channels/101
  • rtsp://admin:password@IP_address:556/Streaming/Channels/101

Проброс портов на роутере¶

  • 192.168.0.101 — 554 (внешний) — 554 (внутренний)
  • 192.168.0.102 — 555 (внешний) — 554 (внутренний)
  • 192.168.0.103 — 556 (внешний) — 554 (внутренний)

Роутер клиента должен иметь статический «белый» IP-адрес.

Все камеры должны быть подключены к электропитанию и интернет.

Источник

Транслируем видеопоток с IP-камеры с помощью WebRTC

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

На это есть как минимум две причины:

1. По мере увеличения числа зрителей Ethernet-трансляции все больше будет ощущаться сперва нехватка толщины канала, а затем и ресурсов самой камеры.

2. Как уже упоминалось выше, IP камера является сервером. Но по каким протоколам она сможет отдать видео браузеру десктопа? Мобильному устройству? Скорее всего это будет HTTP стриминг, где видео фреймы или JPEG картинки передаются через HTTP. HTTP стриминг, как известно не совсем подходит для потокового видео реального времени, хотя хорошо зарекомендовал себя в on-Demand видео, где интерактивность потока и задержка не особо важны. В самом деле, если вы смотрите фильм, задержка видео в несколько секунд не сделает его хуже, если только вы не смотрите этот фильм одновременно с кем то еще. “О нет! Джэк убил её! — пишет Элис в чате Бобу спойлер за 10 секунд до трагической развязки”.

Или же это будет RTSP/RTP и H.264, в этом случае в браузере должен быть установлен плагин видеоплеера, такой как VLC или QuickTime. Такой плагин будет забирать и проигрывать видео, как и сам плеер. Но нам то ведь нужен настоящий браузерный стриминг без установки дополнительных костылей/плагинов.

Читайте также:  Усилитель сигнала wifi тп линк 300

Для начала поснифаем IP камеру чтобы узнать что именно отправляет этот девайс в сторону браузера. В качестве подопытного будет камера D-Link DCS 7010L:

Подробнее об установке и настройке камеры вы сможете прочесть ниже, а здесь мы просто посмотрим что она использует для видео стриминга. При попадании в админку камеры через web-интерфейс наблюдаем примерно такую картинку (пардоньте за пейзаж):

Картинка открывается во всех браузерах и равномерно подлагивает, примерно раз в секунду. Учитывая что и камера и лаптоп, на котором мы смотрим поток подключены к одному маршрутизатору, все должно быть плавно и красиво, но это не так. Похоже на HTTP. Запускаем Wireshark чтобы подтвердить свои догадки:

Здесь видим последовательность TCP фрагментов длиной 1514 байт

и завершающий HTTP 200 OK с длиной принятого JPEG:

Далее заходим в Chrome / Developer Tools / Network и видим в реальном времени как мелькают GET Запросы и картинки, переданные по HTTP:

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

Если заглянуть в HTML страницы админки камеры, увидим вот такой интересный код:

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 пойдет зрителю.

Читайте также:  Вайфай роутер windows 7

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

По идее, вместо пункта 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):

Здесь 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.

Вдруг наc обманули, и видео с 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.

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

Источник

Adblock
detector