Как проверить возможность трансляции RTSP потока с IP камеры в различных Web-браузерах. Настройка RTSP-потока для ip-оборудования Dahua Technology Подключение ip камеры по rtsp
RTSP (Real Time Streaming Protocol) – потоковый протокол реального времени, который содержит простой набор основных команд для управления видеопотоком.
Подключение RTSP источников и IP-камер в видеоконференции
Протокол RTSP позволяет любому пользователю TrueConf подключаться к IP-видеокамерам и прочим источникам медиаконтента, вещающим по данному протоколу, для наблюдения за удаленными объектами. Также пользователь может подключаться к таким камерам для трансляции изображения во время видеоконференции.
Благодаря поддержке протокола RTSP пользователи TrueConf Server могут не только подключаться к IP-камерам, но и транслировать видеоконференции на RTSP-плееры и медиа-серверы. Подробнее об RTSP-трансляциях читайте .
Преимущества использования IP-камер с программными решениями TrueConf
- Установив IP-камеру в офисе или промышленном цеху и подключившись к ней в любой удобный момент, вы сможете контролировать производственный процесс вашей компании.
- Вы можете вести круглосуточное наблюдение за удаленными объектами. К примеру, если вы отправляетесь в отпуск и не хотите оставлять квартиру без присмотра, просто установите там одну или несколько IP-камер. Совершив звонок на одну из таких камер со своего ПК с установленным клиентским приложением TrueConf, вы сможете в любое время подключиться к своей квартире и посмотреть в режиме реального времени, что там происходит.
- В клиентских приложениях TrueConf для Windows, Linux и macOS всем пользователям доступна возможность записи видеоконференций, благодаря которой в процессе видеонаблюдения вы сможете зафиксировать любые события и получить их документальные подтверждения.
В случае сложностей с настройкой или эксплуатацией продукции, ознакомьтесь с часто задаваемыми вопросами и ответами на них.
Как получить подарочную лицензию REVISOR VMS?
Для получения подарочной лицензии Revisor VMS следуйте инструкции. Скачать инструкцию .
У меня 1.3 Мп IP-камера RedLine. Пытаюсь установить ActiveX, но возникает ошибка "HTTP 404 — не найдено", что делать?
В 1.3 Мп видеокамерах модуль ActiveX не встроен, его необходимо установить с диска, который идет в комплекте или загрузить по ссылке
Для камер 4MP:
rtsp://admin:[email protected]адрес:554/ch01/0 - основной поток
rtsp://admin:[email protected]адрес:554/ch01/1 - доп поток
rtsp://admin:[email protected]адрес:554/streaming/mjpeg - поток mjpeg
Для камер 1,3MP и 2 MP
rtsp://admin:[email protected]адрес:554/streaming/video0 - основной поток
rtsp://admin:[email protected]адрес: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-камеры, вообще говоря, не требует применения WebRTC. Камера сама является сервером, обладает IP-адресом и может быть подключена напрямую к маршрутизатору с целью раздачи видео-контента. Так зачем же применять технологию WebRTC?
На это есть как минимум две причины:
1. По мере увеличения числа зрителей Ethernet-трансляции все больше будет ощущаться сперва нехватка толщины канала, а затем и ресурсов самой камеры.
2. Как уже упоминалось выше, IP камера является сервером. Но по каким протоколам она сможет отдать видео браузеру десктопа? Мобильному устройству? Скорее всего это будет HTTP стриминг, где видео фреймы или JPEG картинки передаются через HTTP. HTTP стриминг, как известно не совсем подходит для потокового видео реального времени, хотя хорошо зарекомендовал себя в on-Demand видео, где интерактивность потока и задержка не особо важны. В самом деле, если вы смотрите фильм, задержка видео в несколько секунд не сделает его хуже, если только вы не смотрите этот фильм одновременно с кем то еще. “О нет! Джэк убил её! - пишет Элис в чате Бобу спойлер за 10 секунд до трагической развязки”.
Или же это будет RTSP/RTP и H.264, в этом случае в браузере должен быть установлен плагин видеоплеера, такой как VLC или QuickTime. Такой плагин будет забирать и проигрывать видео, как и сам плеер. Но нам то ведь нужен настоящий браузерный стриминг без установки дополнительных костылей/плагинов.
Для начала поснифаем IP камеру чтобы узнать что именно отправляет этот девайс в сторону браузера. В качестве подопытного будет камера D-Link DCS 7010L:
Подробнее об установке и настройке камеры вы сможете прочесть ниже, а здесь мы просто посмотрим что она использует для видео стриминга. При попадании в админку камеры через web-интерфейс наблюдаем примерно такую картинку (пардоньте за пейзаж):
Картинка открывается во всех браузерах и равномерно подлагивает, примерно раз в секунду. Учитывая что и камера и лаптоп, на котором мы смотрим поток подключены к одному маршрутизатору, все должно быть плавно и красиво, но это не так. Похоже на HTTP. Запускаем Wireshark чтобы подтвердить свои догадки:
Здесь видим последовательность TCP фрагментов длиной 1514 байт
И завершающий HTTP 200 OK с длиной принятого JPEG:
Такой стриминг нам не нужен. Не плавный, дергает HTTP запросы. Сколько таких запросов в секунду выдержит камера? Есть основания полагать что на 10 зрителях и раньше камера благополучно загнется или начнет страшно глючить и выдавать слайды.
Если заглянуть в HTML страницы админки камеры, увидим вот такой интересный код:
If(browser_IE) DW(""); else { if(mpMode == 1) var RTSPName = g_RTSPName1; else if(mpMode == 2) var RTSPName = g_RTSPName2; else if(mpMode == 3) var RTSPName = g_RTSPName3; var o=""; if(g_isIPv6) //because ipv6 not support rtsp. var host = g_netip; else var host = g_host; o+=""; //alert(o); DW(o); }
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 пойдет зрителю.
Для установки нам потребуется SSH-доступ.
Под спойлером – детальное описание выполненных команд
1. Скачали установочный архив сервера:
$wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. Развернули:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Установили:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
В процессе установки ввели внешний IP адрес сервера: 54.186.112.111 и внутренний 172.31.20.65 (тот что Private IP).
4. Запустили сервер:
$service webcallserver start
5. Проверили логи:
$tail - f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. Убедились, что сервер стартовал и готов к работе:
$ps aux | grep Flashphoner
7. Установили и запустили apache:
$yum install httpd
$service httpd start
8. Скачали web-файлы и расположили их в стандартной папке апача /var/www/html
cd /var/www/html
$wget github.com/flashphoner/flashphoner_client/archive/wcs_media_client.zip
$unzip webrtc_media_client.zip
9. Вписали IP адрес сервера в конфиг flashphoner.xml:
10. Остановили firewall.
$service iptables stop
По идее, вместо пункта 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 ):
54.186.112.111/wcs_media_client/?id=rtsp://webrtc-ipcam.ddns.net/live1.sdp
Здесь 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.
Так что в будущем, надеемся увидеть более интересные решения, в которых не нужен будет транскодинг и конвертация потоков и большинство браузеров смогут отыгривать потоки с различных устройств уже напрямую.
Часто возникает вопрос: Как подключить ip камеру к NVR если ее нет в списке совместимости?
Существует два варианта ONVIF и RTSP
Начнем с протокола ONVIF (Open Network Video Interface Forum)
ONVIF это общепринятый протокол для совместной работы IP камер, видеорегистраторов NVR, программного обеспечения, на случай если все устройства разных производителей. ONVIF можно сравнить с английским языком для международного общения людей.
Убедитесь, что подключаемые устройства имеют поддержку ONVIF, на некоторых устройствах ONVIF может быть выключен по умолчанию.
Либо может быть отключена авторизация по ONVIF это значит, что логин/пароль будет всегда по умолчанию
независимо от логина/пароля для WEB
Также стоит отметить, что некоторые устройства используют отдельный порт для работы по протоколу ONVIF
В некоторых случаях ONVIF пароль может отличаться от пароля для WEB доступа.
Что доступно при подключении по ONVIF ?
Обнаружение устройств
Передача видеоданных
Прием и передача аудио данных
Управление поворотными камерами (PTZ)
Видеоаналитика (например обнаружение движения)
Эти параметры зависят от совместимости версий протокола ONVIF. В некоторых случаях часть параметров недоступна, или работает некорректно.
К и с использованием ONVIF
В регистраторах SNR и Dahua протокол ONVIF находится на вкладке Remote Device, строка Manufacturer
Выберите канал к которому будет подключено устройство
Из вкладки Manufacturer выберите ONVIF
Укажите ip адрес устройства
RTSP порт остается по умолчанию
Камеры используют ONVIF
порт 8080
(с 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
Недостатки протокола в том, что кроме передачи видео и аудио данных больше ничего не доступно.
Разберем пример подключения камеры к и с использованием 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 ?
А если совместима то как подключить!?
По некоторым данным, на сегодняшний день, в мире установлены сотни миллионов 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 |
Мы сделали несколько снимков чтобы зафиксировать значения задержки.