Rtsp

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

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

Так как камера долго пролежала в шкафу с другими полезными девайсами и проводами, пришлось отправить ее в Reset, нажав и подержав кнопку на задней стороне камеры 10 секунд. После подключения к сети, на камере загорелась зеленая лампочка и роутер увидел еще одно устройство в локальной сети с IP адресом 192.168.1.37. Заходим в веб-интерфейс камеры и выставляем кодеки и разрешение для тестирования:

Далее заходим в сетевые настройки и узнаем RTSP адрес камеры. В данном случае RTSP-адрес live1.sdp, т.е. Камера доступна по адресу rtsp://192.168.1.37/live1.sdp

Доступность камеры легко проверить с помощью VLC плеера. Media — Open Network Stream.

Мы убедились, что камера работает и отдает видео по RTSP. В качестве сервера для тестирования будем использовать Web Call Server 5. Это стриминг сервер с поддержкой RTSP и WebRTC протоколов. Он будет подключаться к IP-камере по RTSP и забирать видеопоток. Далее раздавать поток по WebRTC. Вы можете установить Web Call Server на свой хост либо запустить готовый инстанс Amazon EC2. После установки необходимо переключить сервер в режим RTSP non-interleaved, который мы обсуждали выше. Это можно сделать добавлением настройки

rtsp_interleaved_mode=false

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

service webcallserver restart

Таким образом, у нас есть сервер, который работает по схеме non-interleaved, принимает пакеты от IP-камеры по UDP, и далее раздаёт по WebRTC (UDP).

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

Правило говорит роутеру перенаправлять весь входящий на порт 554 трафик, на 37 — IP адрес. Далее осталось узнать свой внешний IP-адрес. Это можно сделать за 5-15 секунд, погуглив по слову whatismyip Если у вас дружелюбный NAT и вы знаете внешний IP-адрес, то можно начинать тесты с сервером. Стандартный демо плеер в браузере Google Chrome выглядит так:

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

Как интегрировать видеонаблюдение к Ajax по RTSP протоколу

Итак, RTSP ссылка у нас уже готова — это уже половина дела. Вы можете уже добавить ссылку rtsp://admin:mysecurePassword@192.168.1.52:554/11 в приложение Ajax и смотреть видео локально. Далее, необходимо сделать так, чтобы поток был доступен извне.

Настройка роутера и локального IP-адреса

Первое, что нам необходимо сделать — это чтобы локальный IP-адрес сетевой камеры (или видеорегистратора) не менялся и был постоянным. Например, настроили мы нашу IP-камеру и она получила IP-адрес в локальной сети 192.168.1.52 , таким образом ссылка для RTSP потока будет:

rtsp://admin:mysecurePassword@ 192.168.1.52 :554/11

Здесь есть два варианта настройки IP-камеры:

  • В сетевых настройках для IP-камеры или видеорегистратора использовать статический IP-адрес и прописать ручками все сетевые настройки (шлюз по умолчанию, и т.п.) ;
  • Активировать DHCP — в этом случае IP-адрес камере или видеорегистратору будет давать маршрутизатор (роутер). Для режима DHCP на роутере необходимо сделать привязку MAC-адреса камеры (который уникальный) к IP-адресу — тогда роутер всегда будет давать камере один и тот же IP-адрес.

Привязка MAC-адреса к IP-адресу

Настройка привязки MAC-адреса к IP-адресу у разных производителей роутеров может называться по-разному.

  • Для роутеро TP-Link — это меню «Сеть» — «DHCP-сервер» — «Резервирование адресов»;
  • Для маршрутизаторов Asus — это меню «Локальная сеть» — «Список присвоенных вручную IP-адресов в обход DHCP»;
  • для роутеров Mikrotik — это кнопка «Make Static» в меню «IP» — «DHCP-Server» — «Leases».

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

Выделенный IP-адрес у провайдера

Выделенный IP-адрес от провайдера — эта гарантия того, что IP-адрес в RTSP ссылке для доступа извне не поменяется.

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

Результаты

Подведем итоги и объединим полученные результаты в табличку:

 
Способ отображения
Применение
Задержка
1
RTMP
Там, где важно использование legacy — флэш клиента, Flex или Adobe Air
medium
2
RTMP + HTML5
В браузерах IE, Edge, Mac Safari, если там установлен Flash Player
medium
3
RTMFP
Там, где важно использование legacy — флэш клиента, Flex или Adobe Air и важна низкая задержка
low
4
RTMFP + HTML5
В браузерах IE, Edge, Mac Safari, если там установлен Flash Player и важна низкая задержка.
low
5
WebRTC
В браузерах Chrome, Firefox, Opera на десктопах и мобильных браузерах под Android, где важна real-time задержка.
real-time
6
Websocket
В браузерах, где нет Flash и WebRTC, но нужна средняя или низкая задержка.
medium
7
HLS
Во всех браузерах. Где не важна задержка.
high
8
Android app, WebRTC
В нативных мобильных приложениях  под Android, где требуется real-time задержка.
real-time
9
iOS app, WebRTC
В нативных мобильных приложениях  под iOS, где требуется real-time задержка.
real-time. Для тестирования мы использовали сервер Web Call Server 5, который конвертирует RTSP поток для раздачи в 9 перечисленных направлениях

Для тестирования мы использовали сервер Web Call Server 5, который конвертирует RTSP поток для раздачи в 9 перечисленных направлениях.

пятница, 23 марта 2018 г.

Запись RTSP потока с китайской IP-камеры по датчику движения.

Прикупил я как-то, китайскую IP-Камеру ( Unitoptek Official Store ) на Aliexpress. Давно хотел понаблюдать за курильщиками на лестничной площадке.

сетевые службыТревожный серверменеджер конфигурацийТип сигналаДвижениеВкл— ДЕЛАЕМ СВОЙ СЕРВЕР —

Что нужно для нашей задачи? — Скрипт который постоянно слушает порт: 2345. Если с камеры поступил тревожный сигнал, командой openRTSP пишем поток в файл. — Не забудьте установить openRTSP на сервер! Пролистал темы по сокетам. В итоге набрел на хорошее решение: сервер-демон на языке perl прослушивающий tcp сокет. Очень все подробно описывается и работает на ура. Взял за основу этот скрипт и немного допилил под свои нужды. В итоге получаем: На сервере скрипт socket_server.pl запущенный демоном слушает порт 2345. Как только камера стукнула ему, что есть движение, он запускает еще один перловский скрипт: write_video_file.pl — который пишет видео длительность 30 секунд. Если движение в кадре еще продолжается, пишется второй кусок 30 секундного видео. Особенность этого скрипта в том, что он использует модуль File::Flock::Tiny ( Использование pid-файлов для предотвращения повторного запуска скрипта. ) Зачем я использовал этот модуль? А вот для чего: с камеры идет не один сигнал тревоги, а целая пачка. У меня было до десяти сигналов за 3-4 секунды. socket_server запускал до 10 параллельных потоков записи видео. А модуль File::Flock::Tiny эту проблему как раз и исправил! Ну все! Тестил пару дней. Все работает. Глюков пока не словил. Меня пока полностью удовлетворяет. — САМИ СКРИПТЫ — socket_server.pl

Вполне возможно, что для работы этих скриптов понадобится добавить модуль для перла. Для установки необходимых модулей: cpan install File::Flock::Tiny

Если не получилось, то воспользуемся еще одним методом: sudo apt-get install build-essential дальше ставим сам модуль: sudo perl -MCPAN -e ‘install File::Flock::Tiny’

— ПРОВЕРКА РАБОТЫ — Запустим сервер: ./socket-server.pl Если не руганулся, то все нормально. Для проверки введите следующую команду: netstat -plutn в листинге можно увидеть что-то подобное: tcp 0 0 192.168.20.75:2345 0.0.0.0:* LISTEN 1201/perl

nc -v 192.168.20.75 2345Connection to 192.168.20.75 2345 port [tcp/*] succeeded!

Источник

Как привязать видеопоток IP-камеры или NVR / DVR / XVR видеорегистратора к системе безопасности Ajax

  • Переходим во вкладку » Устройства «.
  • Нажимаем » Добавить камеру «.
  • Выбираем опцию RTSP камера .
  • Указываем: имя камеры / ссылку на видеопоток / комнату , к которой привязывается устройство видеонаблюдения.
  • Нажимаем » Добавить » — видеопоток добавится в приложение Ajax и будет доступен к просмотру.

Для просмотра видеопотока, откройте добавленную камеру в приложении Ajax.

Приложение Ajax позволяет просматривать видео с камер, ставить воспроизведение на паузу и сохранять снимки (делать скриншоты) потока камеры, а также приближать видео (zoomировать). Сменив ориентацию смартфона, поток разворачивается на весь экран (функция автоповорота должна быть включена в настройках смартфона).

Сколько камер можно подключить в приложение Ajax?

Каждое устройство — это один поток видео. Количество подключаемых к Ajax потоков видео зависит от модели хаба: (10 потоков у Hub, 25 у Hub 2 и 50 у Hub Plus).

Доступ к камерам в приложении Ajax

Вам решать, у кого из пользователей Ajax будет доступ к видеопотокам с камер или видеорегистраторов (DVR / NVR / XVR). Доступ к камерам предоставляется пользователям системы безопасности в настройках хаба:

» Устройства » — » Хаб » — » Настройки » — » Пользователи » — » Настройки выбранного пользователя «

Источник

Тестирование задержек 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 768 321

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

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

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

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

Что нужно, что бы передавать живое видео в сеть интернет через RTSP поток?

Современные устройства способны произвести трансляцию потового видео в стандартах RTSP. Для этого используется RTSP-ссылка. Для настройки передачи по RTSP протоколу просмотрите в документации устройства точную URL ссылку для RTSP протокола устройства.

Данную ссылку разработчик указывает в инструкции пользователя устройствам. Недавно способность передавать видео по rtsp протоколу имелась только в IP камерах. Появление новых аналоговых форматов HD AHD, CVI, TVI, а также SDI, не уступающих в качестве изображения, а часто даже превосходящие — привело к резкому развитию видео регистраторов способных выполнять те же функции, что и IP камера.

Простой запуск

Самый простой способ запустить эту программу:

openRTSP URL

где URL — это URL-адрес RTSP для открытия (т. е. начинающийся с «rtsp://»). Программа откроет указанный URL (используя команду RTSP «DESCRIBE»), получит описание SDP сеанса, а затем для каждой аудио/видео подсессии, чей формат полезной нагрузки RTP она понимает, запустит подсессии командами «SETUP» и «PLAY».

Полученные данные для каждой части записываются в отдельный выходной файл, названный в соответствии с его типом MIME. Например, если сеанс содержит аудиоподсекцию MPEG-1 или 2 (тип полезной нагрузки RTP 14), например, MP3, и видеоподсекцию MPEG-1 или 2 (полезная нагрузка RTP 32), то данные каждой подсессии будут извлечены из входящих пакетов RTP и записаны в файлы с именами «audio-MPA-1» и «video-MPV-2» (соответственно). (Затем вам, вероятно, потребуется переименовать эти файлы — присвоив им соответствующее расширение имени файла (например, «.mp3» и «.mpg») — чтобы иметь возможность воспроизводить их с помощью обычных медиаплееров.)

Вы можете использовать опцию «-F ПРЕФИКС-ИМЕНИ-ФАЙЛА», чтобы добавить префикс к имени файла, который записывается для каждой части. (Это может быть полезно, если вы запускаете «openRTSP» несколько раз в одном каталоге для чтения данных из разных сеансов RTSP.)

Извлечение одного потока

Чтобы записать только аудиопоток из сеанса, используйте параметр командной строки «-a». (Точно так же, чтобы записать только видеопоток, используйте параметр «-v».) В этом случае выходной аудиопоток (или видео) будет записан в ‘stdout’, а не в файл (если не указана опция «-P ИНТЕРВАЛ-В-СЕКУНДАХ» (об этом ниже).

Менее подробный диагностический вывод

По умолчанию программа распечатывает (в stderr) каждый полный запрос и ответ RTSP. Для менее подробного вывода используйте параметр «-V» (верхний регистр).

СЕТЕВЫЕ ПРОТОКОЛЫ IP КАМЕР

Основные сетевые протоколы, по которым IP камеры передают или получают информацию:

  • RTSP;
  • TCP;
  • UDP;
  • RTP.

С помощью RTSP-протокола организуется управление видеонаблюдением. Следует понимать, что сам протокол не передаёт данные, а также не выполняет сжатие видеоизображения и не определяет транспортный протокол. Сообщения по данному протоколу пересылаются отдельно от видеопотока.

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

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

При использовании TCP можно быть уверенным в отсутствии повреждений и потерь передаваемых пакетов, однако работает он медленнее своей менее надёжной альтернативы UDP.

В отличие от TCP UDP-протокол не следит за движением информации и не устанавливает предварительного соединения. Однако передаёт данные быстрее за счёт отсутствия необходимости дублирования потерявшихся при передаче пакетов.

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

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

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

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

В связи с этим следует упомянуть стандарт ONVIF.

ONVIF реализуется организацией Open Network Video Interface Forum, и его цель — устранить проблему несовместимости между IP камерами и приёмными устройствами цифрового сигнала.

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

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

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

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

Протоколы передачи видео

  1. потоковые протоколы;
  2. cегментные протоколы.

Потоковые протоколыRTMP, webRTC, RTSP/RTPсегментных протоколов

Потоковые протоколы

он использует TCPгарантирует доставку и последовательность пакетовизъять их оттуда нельзяTCP крайне не подходит для стриминга

  • 1,1 Мбит/с трафика;
  • 0,1% packet loss;
  • 300 мс средний RTT.

среднедневной процент потери пакетов более 3%на TCP делать не будемПротокол WebRTCпренебрегает потерямиRTP-стримингНо это очень сложно

Сегментные протоколы

MPEG-DashHLS188 байт26 млн пакетоввсегда появляется задержкарешение использовать фрагментный стриминг для трансляции не очень хорошее

  • latency, который они дают между трансляцией и смотрящим;
  • complexity (сложность).

Что мы хотим?

Какие есть еще варианты?

  1. Многопоточность, то есть мы имеем несколько потоков — управляющий, видео, аудио.
  2. Опциональная гарантия доставки — управляющий поток имеет 100% гарантию, видео нам нужно меньше всего — мы там можем дропать фрейм, аудио нам все-таки бы хотелось.
  3. Приоритезация потоков — чтобы аудио уходило вперед, а управляющий вообще летел.
  4. Опциональное шифрование: или все данные, или только заголовки и критичные данные.

чем меньше время ожидания, тем хуже качество

Полный список опций

Это краткое описание опций для команд openRTSP и playSIP.

-4

вывести файл в формате ‘.mp4’ (в ‘stdout’, если также не задана опция «-P ИНТЕРВАЛ-В-СЕКУНДАХ»)

-a

воспроизводить только аудиопоток (в ‘stdout’, если также не задана опция «-P ИНТЕРВАЛ-В-СЕКУНДАХ»)

-A НОМЕР КОДЕКА

укажите номер статического формата полезной нагрузки RTP аудиокодека для запроса с сервера (только «playSIP»)

-b РАЗМЕР БУФЕРА

изменить размер буфера выходного файла

-B РАЗМЕР БУФЕРА

изменить размер входного буфера сетевого сокета

-c

воспроизводить непрерывно

-C

явно запрашивать многоадресный поток, даже если в ответе сервера «DESCRIBE» не указан многоадресный адрес

(Обратите внимание, что не все серверы поддерживают это.) (Только «openRTSP»). -d ДЛИТЕЛЬНОСТЬ

-d ДЛИТЕЛЬНОСТЬ

укажите явную продолжительность

-D МАКСИМАЛЬНЫЙ-РАЗРЫВ-МЕЖДУ-ПАКЕТАМИ

указать максимальный период бездействия перед выходом

-E ПОЛНОЕ ВРЕМЯ

запросить, чтобы сервер завершил потоковую передачу в указанное абсолютное время (формат: «ГГГГММДДТЧЧММССЗ» или «ГГГГММДДТЧЧММСС.долиZ») (используется только с -U АБСОЛЮТНОЕ-ВРЕМЯ)

-f ЧАСТОТА

укажите частоту кадров видео (используется только с «-q», «-4» или «-i»)

-F ПРЕФИКС ФАЙЛА

укажите префикс для каждого имени выходного файла

-g USER-AGENT

укажите имя пользовательского агента для использования в исходящих запросах

-h ВЫСОТА

укажите высоту видеоизображения (используется только с «-q», «-4» или «-i»)

-H

выводит «подсказку» QuickTime для каждой аудио/видеодорожки (используется только с «-q» или «-4»)

-i

вывести файл в формате ‘.avi’ (в ‘stdout’, если также не задана опция «-P ИНТЕРВАЛ-В-СЕКУНДАХ»)

-I ИНТЕРФЕЙС-ИЛИ-IP

указать конкретный сетевой интерфейс для получения данных

-k ПОЛЬЗОВАТЕЛЬ ПАРОЛЬ

укажите имя пользователя и пароль, необходимые для аутентификации входящей команды «REGISTER» (используется только с «-R»)

-K

Периодически отправляйте команду RTSP «OPTIONS», чтобы поддерживать соединение. (Это полезно для серверов с ошибками, которые вместо этого не слушают наши периодические пакеты RTCP «RR».)

-l

попытаться компенсировать потерю пакетов (используется только с «-q», «-4» или «-i»)

-m

выводить каждый входящий кадр в отдельный файл

-M ПОДТИП MIME

укажите подтип MIME динамического формата полезной нагрузки RTP, который аудиокодек запрашивает у сервера (только «playSIP»)

-n

получать уведомление, когда начинают поступать пакеты данных RTP

-o

запросить возможные параметры команды сервера, не отправляя «DESCRIBE» (только «openRTSP»)

-O

не запрашивать возможные команды сервера; просто отправить «DESCRIBE» (только «openRTSP»)

-p НАЧАЛЬНЫЙ-ПОРТ

укажите номер(а) клиентского порта

-P ИНТЕРВАЛ-СЕКУНДЫ

записывать новые выходные файлы каждые ИНТЕРВАЛ-В-СЕКУНДАХ секунд

-q

вывести файл формата QuickTime ‘.mov’ (в ‘stdout’, если также не задана опция «-P ИНТЕРВАЛ-В-СЕКУНДАХ»)

-Q

выводить статистику QOS о потоке данных (при выходе из программы)

-r

воспроизводить потоки RTP, но не получать их самостоятельно

-R (или -R ПОРТ)

ожидать входящей команды «REGISTER» с указанием URL «rtsp://» для воспроизведения. Этот параметр используется вместо URL-адреса «rtsp://» в командной строке. (только «openRTSP»)

-s НАЧАЛО

запросить у сервера поиск указанного времени (в секундах) перед потоковой передачей

-S БАЙТЫ-СДВИГА

предполагать простой формат полезной нагрузки RTP (пропуск специального заголовка указанного размера)

-t

передавать данные RTP/RTCP через TCP, а не через (обычный) UDP. (только «openRTSP»)

-T ПОРТ

как «-t», за исключением использования туннелирования RTSP через HTTP. (только «openRTSP»)

-u ПОЛЬЗОВАТЕЛЬ ПАРОЛЬ

укажите имя пользователя и пароль для дайджест-аутентификации

-U ПОЛНОЕ-ВРЕМЯ

запросить у сервера поиск указанного абсолютного времени (формат: «ГГГГММДДТЧЧММССЗ» или «ГГГГММДДТЧЧММСС.доляZ») перед потоковой передачей

-v

воспроизводить только видеопоток (в ‘stdout’, если также не задана опция «-P ИНТЕРВАЛ-В-СЕКУНДАХ»)

-V

печатать менее подробный диагностический вывод

-w ШИРИНА

укажите ширину видеоизображения (используется только с «-q», «-4» или «-i»)

-y

попробовать синхронизировать аудио и видео треки (используется только с «-q» или «-4»)

-z СКОРОСТЬ

запросить, чтобы сервер масштабировал поток (ускоренная перемотка вперед, медленное или обратное воспроизведение)

Способ 5 — WebRTC

В данном случае Flash не используется совсем и видеопоток проигрывается средствами самого браузера, без использования сторонних плагинов. Это работает и в Android Chrome и Android Firefox — мобильных браузерах, где Flash не установлен. WebRTC дает самую низкую задержку — менее 0.5 секунды.

Код плеера тот же:

var session = Flashphoner.createSession({urlServer:"wss://192.168.88.59:8443"});
session.createStream({name:"rtsp://192.168.88.5/live.sdp", display:myVideo}).play();

Автоматически определяется поддержка WebRTC, и если поддерживается то поток играет по WebRTC.

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

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

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

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

Видеорегистраторы наблюдения следующего поколения с трансляцией потокового видео RTSP:

В этой статье приводим пример настройки RTSP протокола для канала передачи видео изображения с видео рекордеров CAICO TECH CCTV.

Видеорегистраторы CAICO TECH CCTV в отличии большинства других видео регистраторов способны поддерживать автоматические настройки для передачи видео по RTSP протоколу.

UPnP RTSP — для автоматической трансляции потока установите отметку из двух возможных вариантов настроек и выберете — автоматические или ручные настройки.

  1. Автоматическая настройка видеорегистратора протокола RTSP UPnP:

В раскладке настройка меню раздела UPnP- указать авто (См рисунок1). Настройки окончены. Не забывайте — роутер> настройки> пробросить порты для передачи видео с 554 порта видеорегистратора. Также нужен постоянный IP адрес если захотите передавать видео в сеть при работе с серверами способными передавать прямой видео поток ONLINE-вещания.

Для просмотра на VLS медиа плеере и других устройств потребуется ссылка URL RTSP как выглядит и как пользоваться показано ниже! Обратите внимание эта ссылка верна только для устройств торговой марки CAICO TECH CCTV. RTSP ссылка для видео рекордеров CAICO TECH CCTV следующего поколения показана ниже в описании настроек:

RTSP ссылка для видео рекордеров CAICO TECH CCTV следующего поколения показана ниже в описании настроек:

Есть ли минусы для видеорегистратора ели в нем есть возможность трансляции RTSP потока?

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

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

Все остальные настройки видеорегистратора производиться согласно настройке вашего типа видеорегистратора, которые приведены в руководстве пользователя.

Настройка видеорегистратора; протокол RTSP UPnP:

В раскладке настройка меню раздела UpnP- указать авто / поддерживающую принцип Plug and Play.

На этом в регистраторе CAICO настройки окончены.

Рисунок 1 авто настройка RTPS протокола

Важно! Не забывайте что необходимо пробросить порты роутера для передачи видео с 554 порта видеорегистратора. Также нужен постоянный IP адрес если захотите передавать видео в сеть при работе с серверами способными передавать прямой видео поток Online вещания

Для просмотра на VLS медиа плеере и других устройств вам также потребуется корректная ссылка URL RTSP:// как она выглядит и как пользоваться показано ниже!

При этом данная ссылка URL RTSP верна только для устройств торговой марки CAICO TECH CCTV.

RTSP ССЫЛКУ ДОСТАТОЧНО ВВЕСТИ В ПОЛЕ URL RTSP

Реализация

Серверы

  • Darwin Streaming Server — Open-sourced версия QuickTime Streaming Server, которая поддерживается Apple;
  • Feng — Open-source потоковый сервер, разработанный итальянской командой университета Politecnico di Torino для проекта LScube;
  • FFmpeg — включает ffserver GPL или LGPL;
  • Helix Universal Server — коммерческий потоковый сервер для RTSP, RTMP, iOS, Silverlight и HTTP потоковых медиа-клиентов;
  • LIVE555 — Open source C++ сервер и клиентские библиотеки, которые используют известные клиенты, например VLC и mplayer;
  • Managed Media Aggregation — написан в полностью управляемом коде;
  • pvServer — ранее назывался Packet Video Streaming Server, это потоковый сервер продукта Alcatel-Lucent;
  • QuickTime Streaming Server — потоковый сервер с закрытым исходным кодом от Apple, который поставляется с Mac OS X Server;
  • VideoLAN — Open-source медиа-проигрыватель и потоковый сервер;
  • VX30 — потоковый видео сервер и встроенный Java клиент от Maui X-Stream;
  • Windows Media Services — потоковый сервер от Microsoft, который использует RTSP, модифицированный с помощью расширений Windows Media;
  • Wowza Media Server — мультиформатный потоковый сервер для RTSP/RTP, RTMP, MPEG-TS, ICY, HTTP;
  • Xenon Streaming Server — мобильный потоковый сервер от Vidiator Technology:
  • YouTube.

Клиенты

  • cURL
  • FFmpeg
  • GStreamer
  • Media Player Classic
  • MPlayer
  • MythTV via Freebox
  • QuickTime
  • RealPlayer
  • Skype
  • Spotify
  • VLC media player
  • Winamp
  • Windows Media Player
  • xine
  • JetAudio
  • Managed Media Aggregation
  • Astra
  • omxplayer

Вывод файла в формате «.mov», «.mp4» или «.avi»

Используйте параметр «-q» для вывода полученных данных на стандартный вывод в виде файла Apple QuickTime в формате «.mov». Каждая полученная часть будет иметь свой собственный трек в выходном файле.

Аналогично, опция «-4» создаёт файл в формате .mp4 (то есть MPEG-4).

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

Если сеанс содержит часть видео, вы также должны использовать параметры «-w ШИРИНА», «-h ВЫСОТА» и «-f ЧАСТОТА», чтобы указать ширину и высоту (в пикселях), и частоту кадров (в секунду) соответствующей видеодорожки. (Если эти параметры опущены, используются значения ширина = 240 пикселей; высота = 180 пикселей; частота кадров = 15). Эти значения важны; если они неверны, ваш файл может вообще не воспроизводиться!

В качестве альтернативы, если описание SDP сеанса содержит атрибут уровня мультимедиа «a=x-dimensions: ШИРИНА,ВЫСОТА», то вместо этого будут использоваться эти значения (в этом случае вам не нужно использовать «-w» и «-h»). Точно так же, если описание SDP сеанса содержит атрибут уровня мультимедиа «a=x-framerate: ЧАСТОТА», то вместо этого будет использоваться это значение (в этом случае вам не нужно использовать опцию «-f»).

Если полученный файл фильма QuickTime содержит несинхронизированные аудио- и видеодорожки, то вы можете использовать параметр «-y», чтобы попытаться создать синхронизированные аудио/видеодорожки. (Этот параметр работает путём прослушивания пакетов RTCP «Sender Report», содержащих информацию о синхронизации времени — для каждого потока. Некоторые исходные несинхронизированные данные могут быть отброшены.)

Параметр «-H» также создаёт QuickTime ‘hint track’ для каждой аудио- или видеодорожки. Это полезно, если вы позже захотите стримить получившийся файл «.mov» или «.mp4».

Примечание: поддержка openRTSP для создания файлов формата QuickTime весьма ограничена. В настоящее время поддерживается только звук PCM (u-law и a-law), MPEG-4, GSM и QCELP (также известный как PureVoice), и только MPEG-4, H.263/H.263+ и H.264 видео поддерживается. (Кроме того, для создания файлов формата QuickTime с подсказками звук QCELP в настоящее время не поддерживается.)

Параметр «-i» создаёт файл в формате .avi. (Эта функция поддерживается не полностью. Поддерживается видео MPEG-1, 2 или 4, JPEG и H.263, а также необработанный звук PCM или u-law. Однако MPEG и другие аудиокодеки ещё не поддерживаются.)

Важное примечание: если вы выводите файл формата «.mov», «.mp4» или «.avi», вы должны позволить «openRTSP» работать до конца, или же завершить его чисто, сигнализировав SIGHUP или SIGUSR1. Вы не должны завершать его, используя Ctrl+c, иначе выходной файл не будет записан должным образом.

Связанная статья: Как записать видео с IP камеры (RTSP поток)

Оцените статью
Рейтинг автора
5
Материал подготовил
Илья Коршунов
Наш эксперт
Написано статей
134
Добавить комментарий