D-link

Real-Time Streaming Protocol (RTSP) в Nimble Streamer

Nimble Streamer позволяет обрабатывать любые из допустимых типов RTSP потоков:

  • анонсированные RTSP потоки, опубликованные в Nimble;
  • потоки, доступные через публичные URL (т.е. принимаемые потоки) по TCP, UDP и HTTP (VAPIX).

Контент можно также брать на вход по протоколам RTMP, SRT, MPEG2TS, Icecast, SHOUTcast и даже конвертировать HLS в RTSP.Доступна компенсация чередования (interleaving) для случаев, когда видео и аудио в потоках рассинхронизированы.Поддерживаются LATM и ADTS AAC заголовки.

Кодеки

Видео:

  • H.264 на вход и выход поддерживается для всех протоколов
  • H.265 на вход по RTSP и MPEG-TS, на выход по RTSP, MPEG-DASH, MPEG-TS и HLS
  • VP8 и VP9 на вход и выход

Аудио:

  • AAC на вход и выход поддерживается для всех протоколов
  • AC3 и E-AC3 на вход для RTSP и MPEG-TS, на выход для RTSP, MPEG-TS и HLS
  • MP3 на вход и выход
  • PCM G.711 (a-law и μ-law) на вход и выход

Узнайте больше о поддержке кодеков.

Преобразование потоков в HLS и MPEG-DASH

Nimble Streamer перепаковывает RTSP в потоки HLS и DASHNimble поддерживает несколько запасных pulled RTSP источников для обеспечения надёжности.Переключение на запасные публикованные потоки RTSP поддерживается через технологию hot-swap.Эти потоки могут быть использованы для создания потоков с адаптивным битрейтом (ABR) через простой веб-интерфейс.

Проигрывание

Nimble Streamer поддерживает исходящие потоки RTSP для TCP inteleaved проигрывания с полным набором функциональности защиты потоков и псеводнимов. Таким образом Нимбл предоставляет потоки RTSP как для просмотра, так и для дальнейшей передачи на другие сервера.

Запись

Nimble Streamer поддерживает функциональность DVR, которая позволяет записывать входящие потоки RTSP для последующего воспроизведения через HLS и MPEG-DASH.

Обработка произвольных потоков по запросу

Nimble может брать RTSP поток для создания потоков RTMP и HLS по запросу, в случае, если вы не хотите круглосуточно передавать данные в каких-либо источников.Подобное поведение выгодно, когда у вас много потоков, которые смотрят не всё время. Также это выгодно в случае, если есть множество камер, просмотр которых происходит лишь время от времени.

Повторная публикация

Для входящих опубликованных и принимаемых потоков можно установить повторную публикацию RTSP.При таком сценарии можно перебросить живую трансляцию на edge-сервера для обеспеспечения устойчивой работы вещания.

Поддержка H.265/HEVC

В Nimble есть поддержка HEVC в RTSP на выходе. В качестве источника можно использовать как RTSP, так и MPEG-TS по UDP и TCP.

Перепаковка в другие протоколы вещания

Применяемый механизм может позволяет перепаковать контент RTSP в следующие протоколы.

  • RTMP (посмотреть пример настройки сценария)
  • MPEG2TS
  • SLDP
  • SRT
  • Icecast audio

«Горячее» переключение

Возможности по переключению потоков позволяют заменять исходный поток без заиканий и артефактов:

  • Переключение на пришедший поток для покрытия таких требований как U.S. Emergency Alert System.
  • Переключение на запасной поток, если основной вышел из строя — можно показать настроечную таблицу или другой активный канал.

API и управление

Вещание по RTSP можно контролировать несколькими способами помимо веб-интерфейса WMSPanel.

  • Функциональность контроля за публикацией RTSP позволяет обезопасить точки, принимающие вещание из внешних источников. В неё включены несколько уровней управления, включая внешний обработчик в виде веб-приложения, который вы можете применить к процессу вещания на основе вашей бизнес-логики. Эта функциональность очень полезна решений, связанных с вещанием с мобильных устройств.Ознакомьтесь с обзорной статьёй, чтобы узнать больше о преимуществах этого решения, а также с детальным описанием настройки с примерами работы.
  • Нотификации доступности потоков через push API для publish/unpublish потоков RTSP
  • Набор методов API WMSPanel позволяет управлять всеми возможностями RTSP.

Псевдонимы (aliasing)

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

Пример использования

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

Легкая процедура установки и обновления

Nimble Streamer ставится в несколько простых шагов и может быть обновлен до последней версии с помощью двух-трех простых команд в консоли.

Свяжитесь с нами, если нужна помощь и воспользуйтесь поиском по документации, там есть ответы на многие вопросы.

Подводный камень #3 — Битрейт зрителей и потери

Каждый подключившийся к серверу зритель трансляции также имеет определенную пропускную способность на Download. Если IP-камера отправляет поток, превышающий возможности канала зрителя (например камера отправляет 1 Mbps, а зритель может принять только 500 Kbps), то на этом канале будут большие потери и, как следствие фризы видео или сильные артефакты.

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

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

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

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

  • 200 Kbps
  • 1 Mbps

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

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

Способ подстройки Количество ядер на сервере
1 Транскодировать видеопоток под каждого зрителя под требуемый битрейт N — количество зрителей
2 Транскодировать видеопотоки по группам пользователям G — количество групп зрителей
3 Подготовить потоки с камеры заранее в нескольких разрешениях и битрейтах

Из таблицы видно, что мы можем сместить транскодинговую нагрузку на камеру либо отдать транскодирование на сервер. Варианты 2 и 3 при этом выглядят наиболее оптимальными.

Как настроить сетевое оборудование

Хотя процесс настройки схож во многих роутерах, названия параметров и настроек у разных производителей могут отличаться. Прежде чем приступать к настройке, ознакомьтесь с инструкциями к оборудованию. В статье камера будет подключаться к роутеру TP-Link (модель: TL-WR842N, версия прошивки: 150921).

Если вы подключаете IP-камеру внутри корпоративной сети — обратитесь к вашему системному администратору. Он поможет с настройкой.

  1. Резервирование IP-адреса за камерой.
  2. Перенаправление сетевых портов.

Как присвоить IP-адрес камере

Существует два способа присвоить камере постоянный IP-адрес:

  1. В настройках роутера
  2. В настройках камеры

В примере мы разберём первый способ.

Прежде чем приступить к резервированию IP-адреса, включите DHCP в настройках вашей IP-камеры. Процедура описана в инструкции производителя.

Процесс резервирования IP-адреса:

1. Подключите к камере кабель питания и сетевой кабель роутера.

2. Напишите в адресной строке браузера IP-адрес вашего роутера, чтобы перейти в его настройки.

IP-адрес роутера может зависеть как от настроек сети, так и от модели сетевого оборудования. Как правило, IP-адрес указан в документации вашего роутера (чаще всего это 192.168.0.1 или 192.168.1.1). Узнать его можно и с компьютера или ноутбука, подключенного к вашей сети.

Как узнать IP-адрес роутера в Windows

1. Откройте командную строку

Первый способ: одновременно нажмите WIN и R , введите cmd и нажмите Enter.

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

2. Введите команду ipconfig и нажмите Enter. IP-адрес роутера будет указан в строке Основной шлюз.

Как узнать IP-адрес роутера в macOS
  1. Откройте Системные настройки.
  2. Выберите меню Сеть и нажмите кнопку Дополнительно.
  3. Откройте вкладку TCP/IP. IP-адрес вашего роутера указан в строке Маршрутизатор.

При входе в настройки роутер запросит логин и пароль. Они указываются в инструкции, на коробке или корпусе устройства.

3. Перейдите в настройки DHCP. Если DHCP выключен — включите функцию и перезагрузите роутер.

4. Перейдите в DHCP Client List. Вы увидите список подключенных к роутеру устройств. В нем необходимо определить вашу камеру и скопировать её MAC-адрес.

В большинстве случаев камера подписана Unknown или имеет название модели или марки производителя.

5. Перейдите в меню Address Reservation и нажмите Add New. Вставьте МАС-адрес камеры и задайте ей IP-адрес. Чтобы избежать конфликтов IP-адресов мы рекомендуем зарезервировать за камерой тот IP-адрес, который был выдан ей роутером автоматически. Учитывайте, что при подключении нескольких камер необходимо резервировать IP-адрес для каждой из них.

Резервирование IP-адреса необходимо, чтобы IP-адрес камеры не менялся после её переподключения или перезагрузки роутера.

6. Перезагрузите или переподключите к роутеру IP-камеру. Теперь она имеет статический IP-адрес внутри вашей сети.

Как перенаправить сетевые порты

Если у вашего оборудования есть функция UPnP — включите её в настройках IP-камеры и роутера. После этого порты будут перенаправлены автоматически.

Как включить функцию UPnP на роутере TP-link
  1. Перейдите в настройки роутера.
  2. Выберите категорию Forwarding.
  3. Перейдите во вкладку UPnP и нажмите Enable, если опция была отключена.

1. В настройках роутера перейдите в раздел Forwarding. Выберите Port Triggering и нажмите Add New.

2. Укажите сетевые порты: внутренний (который используется камерой внутри сети, значение указано в инструкции производителя) и внешний (который будет доступен из внешнего мира).

Не рекомендуется использовать такие сетевые порты: 20, 21, 22, 53, 80, 110, 138, 139, 443, 3306, 3128, 3389, 5900, так как они чаще всего используются различными служебными сервисами.

Учитывайте, что внешний порт должен быть доступным (открытым в настройках роутера и не занятым каким-либо сервисом). Проверить это можно при помощи онлайн-сервисов, например: 2ip.ru. Если у вас возникли проблемы с определением открытого порта — обратитесь к вашему интернет-провайдеру.

По умолчанию IP-камеры используют 554 порт, но номер порта может отличаться у разных производителей. Точное значение можно узнать в инструкции устройства.

3. Сохраните настройки и перезагрузите роутер. Порты перенаправлены.

При подключении нескольких IP-камер для каждой из них необходимо выделить и настроить свои сетевые порты.

Тестирование 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 адрес вашей камеры. Сервер будет пытаться установить соединение именно по этому адресу.

Способ 6 — Websockets

WebRTC и Flash не покрывают все браузеры и платформы. Например, в браузере iOS Safari эти технологии не поддерживаются.

На iOS Safari можно доставить видеопоток по транспорту Websocket (TCP соединению между браузером и сервером). В этот туннель можно завернуть сконвертированный с RTSP видеопоток. После того, как бинарные данные придут их можно декодировать с помощью JavaScript и отрисовать на Canvas HTML5-элементе.

Именно этим занимается Websocket — плеер при работе в браузере iOS Safari, а его код снаружи выглядит также:

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

Это чем-то похоже на подход с флэшкой, когда под HTML5 лежит swf-элемент. В данном случае, под HTML5-страницей лежит не swf-объект, а JavaScript-приложение, которое тянет данные по вебсокетам, декодирует и отрисовывает на Canvas в нескольких потоках.

Так выглядит RTSP поток на Canvas в браузере iOS Safari

Реализация

Серверы

  • 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

Шаг 2. Запускаем серверное ПО SL NEO и настраиваем параметры выходного IP-потока

Дальнейшие настройки будут осуществляться из контрольной панели — Administrator Control Panel. Вход в консоль управления производится локально с сервера, либо с любой машины в сети по адресу http://ip address:7901. Следует выполнить вход в консоль управления от имени администратора. 

После входа в консоль управления, в левом меню консоли выбираем Manage. Выбираем закладку Video IO Boards, в окне Ethernet port выбираем Add Service. В появившемся окне выбираем Mode — Playout, в закладке General устанавливаем требуемое значение Video Mode.

Переходим к закладке MPEG2 TS Paramerters. В закладке Output в поле MUX Bitrate необходимо задать суммарную скорость выходного потока. В закладке Video выбираем алгоритм кодирования — MPEG2 либо MPEG4/AVC (H.264), задаем параметры разрешения, скорость потока видео можно оставить в режиме Auto. Далее необходимо задать параметры кодирования или оставить настройки по умолчанию. В закладке Audio необходимо задать параметры кодирования аудиотрека или оставить настройки по умолчанию.


Переходим к закладке IP Parameters. В ней выбирается протокол вещания (UDP или RTP). 

Для генерации unicast IP-трафика в поле Address указывается IP адрес и порт машины, на которую будет направлен поток.

Для генерации multicast IP-трафика в поле Address указывается IP адрес из диапазона 224.0.0.0 — 239.255.255.255 и порт. В поле Multicast IF следует указать физический IP адрес сетевого адаптера сервера, с которого будет формироваться multicast-поток.

Параметр TTL — Time To Live (время жизни пакета) — количество роутеров, через которые может пройти пакет. Пакеты с TTL=1 распространяются только в одной подсети.

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

Затем в закладке Manage консоли управления следует выбрать только что настроенный сервис Playout, закрепленный за сетевым адаптером и отвечающий за формирование IP потока и подать на его вход (поле Input) поток с выхода сервиса формирования программного канала Program_1 (или выбрать необходимый источник из списка).

Проверить правильность настроек можно с помощью VLC Player.

Для приема потока UDP unicast, в настройках VLC на принимающей стороне с следует прописать udp://@:port.

Для приема потока UDP multicast, в настройках VLC на принимающей стороне следует прописать udp://@multicast_ip:port.

Кроме этого, если сервер генерирует поток в режиме Unicast, к нему можно подключиться по RTSP, для этого нужно использовать URL: rtsp://server_ip:8554/. Если сервис воспроизведения по IP (playout) имеет имя Playout_1, в VLC на приемной стороне необходимо прописать URL: rtsp://server_ip:8554/Playout_1.

RTSP to MSE

Еще один кейс использования MSE over Websockets — это воспроизведение видео с IP-камеры или другой системы, которая отдает видеопоток по RTSP.

IP камера, как правило, нативно поддерживает H.264 и AAC кодеки, поэтому кодеки полностью совпадают с теми, что используются на MSE. Это помогает избежать транскодинга, поглощающего ресурсы CPU.

Схема трансляции следующая:

  1. Браузер просит RTSP поток.
  2. Сервер устанавливает соединение с камерой и запрашивает этот поток у камеры по RTSP.
  3. Камера отдает RTSP поток. Начинается стриминг.
  4. RTSP поток конвертируется в Websockets на стороне сервера и спускается на браузер.
  5. Браузер передает поток MSE-плееру для воспроизведения.

Для работы с RTSP потоком используется тот же самый плеер, который мы показывали выше. Просто задается полный урл RTSP потока вместо имени.

На момент написания статьи, мы протестировали MSE плеер в Chrome, Firefox, Safari.

Управляющие команды протокола

По синтаксису и операциям протокол RTSP похож на HTTP. Однако между протоколами RTSP и HTTP есть ряд существенных различий. Одно из основных заключается в том, что в первом и сервер, и клиент способны генерировать запросы. Например, видеосервер может послать запрос для установки параметров воспроизведения определенного видеопотока. Далее, протоколом RTSP предусматривается, что управление состоянием или связью должен осуществлять сервер, тогда как HTTP вообще никакого отношения к этому не имеет. Наконец, в RTSP данные могут передаваться вне основной полосы (out-of-band) другими протоколами, например RTP, что невозможно в случае HTTP. RTSP-сообщения посылаются отдельно от мультимедийного потока. Для них используется соединение по специальному порту, по умолчанию с номером 554.

Запрос на сервер посылается в текстовом виде в формате: «метод абсолютный_адрес контент версия_протокола«. Вместе с запросом могут быть переданы дополнительные служебные поля (на новых строчках запроса).

Пример запроса: «PLAY rtsp://server/path/test.mpg RTSP/1.0»


Real Time Streaming Protocol

Options

Возвращает список поддерживаемых методов (OPTIONS, DESCRIBE и т.д.)

C->S:  OPTIONS rtsp://example.com/media.mp4 RTSP/1.0
       CSeq: 1
       Require: implicit-play
       Proxy-Require: gzipped-messages
S->C:  RTSP/1.0 200 OK
       CSeq: 1
       Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

Describe

Запрос описания контента, описывает каждый трек в формате SDP

C->S: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 2
S->C: RTSP/1.0 200 OK
      CSeq: 2
      Content-Base: rtsp://example.com/media.mp4
      Content-Type: application/sdp
      Content-Length: 460
      m=video 0 RTP/AVP 96
      a=control:streamid=0
      a=range:npt=0-7.741000
      a=length:npt=7.741000
      a=rtpmap:96 MP4V-ES/5544
      a=mimetype:string;"video/MP4V-ES"
      a=AvgBitRate:integer;304018
      a=StreamName:string;"hinted video track"
      m=audio 0 RTP/AVP 97
      a=control:streamid=1
      a=range:npt=0-7.712000
      a=length:npt=7.712000
      a=rtpmap:97 mpeg4-generic/32000/2
      a=mimetype:string;"audio/mpeg4-generic"
      a=AvgBitRate:integer;65790
      a=StreamName:string;"hinted audio track"

Setup

Запрос установки соединений и транспорта для потоков.

C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=8000-8001
S->C: RTSP/1.0 200 OK
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;ssrc=1234ABCD
      Session: 12345678

Play

Старт вещания.

C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 4
      Range: npt=5-20
      Session: 12345678
S->C: RTSP/1.0 200 OK
      CSeq: 4
      Session: 12345678
      RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012

Teardown

Остановка вещания.

C->S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 8
      Session: 12345678
S->C: RTSP/1.0 200 OK
      CSeq: 8

Record

Запрос на записывание контента сервером

C->S: RECORD rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 6
      Session: 12345678
S->C: RTSP/1.0 200 OK
      CSeq: 6
      Session: 12345678

GET_PARAMETER

Запрос GET_PARAMETER извлекает значение параметра, заданного в URI.

S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 9
      Content-Type: text/parameters
      Session: 12345678
      Content-Length: 15
      packets_received
      jitter
C->S: RTSP/1.0 200 OK
      CSeq: 9
      Content-Length: 46
      Content-Type: text/parameters
      packets_received: 10
      jitter: 0.3838

SET_PARAMETER

Установка параметров сервера

C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 10
      Content-length: 20
      Content-type: text/parameters
      barparam: barstuff
S->C: RTSP/1.0 451 Invalid Parameter
      CSeq: 10
      Content-length: 10
      Content-type: text/parameters
      barparam

Redirect

Перенаправление на другой контент.

S->C: REDIRECT rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 11
      Location: rtsp://bigserver.com:8001
      Range: clock=19960213T143205Z-

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

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

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

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

Ссылки

Web Call Server 5 — сервер для раздачи RTSP потокаFlash Streaming — пример swf приложения, проигрывающего потоки по RTMP и RTMFP. Способы 1 и 3.Source — исходный код swf приложения на Flex / AS3.

Player — пример web-приложения, которое воспроизводит RTSP поток по RTMP, RTMFP, WebRTC, Websocket. Способы 2,4,5,6.Source — исходный код веб-плеера.

HLS плеер — пример web-плеера, играющего HLS. Способ 7.Source — исходный код HLS плеера.

Android плеер WebRTC — пример мобильного приложения, которое играет поток по WebRTC. Способ 8.Source — исходный код мобильного приложения.

iOS плеер WebRTC — пример мобильного приложения, которое играет WebRTC поток. Способ 9.Source — исходный код мобильного приложения.

Сравнение с другими технологиями воспроизведения

Теперь посмотрим на MSE в сравнении с другими технологиями воспроизведения видео в браузере.

Для сравнения возьмем 4 технологии:

  • WebRTC
  • Flash
  • HLS
  • Canvas + Web Audio
 

MSE

WebRTC

Flash

HLS

Canvas

Поддержка Chrome, Firefox

Да

Да

Да

Да

Да

Поддержка iOS Safari

Нет

Нет

Нет

Да

Да

Поддержка Mac Safari

Да

Нет

Да

Да

Да

Задержка

3

0.5

3

20

3

Разрешение full HD

Да

Да

Да

Да

Нет

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

Если задержка абсолютно не важна, стоит использовать HLS, как наиболее универсальный вариант. Если же низкая задержка критична, нужно использовать комбинацию из WebRTC, Flash, Canvas, MSE чтобы покрыть большинство браузеров. При строгих требованиях к задержке

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

Как работает передача видео с IP-камер в приложения Ajax

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

Пример RTSP-ссылки для камеры Hikvision:

расшифровка ссылки:

  • rtsp — тип протокола
  • admin — логин учётной записи Hikvision
  • 12345 — пароль учётной записи Hikvision
  • 192.168.200.11 — IP-адрес камеры
  • 554 — RTSP порт камеры
  • 101 — идентификатор номера камеры и канала. Первая цифра: номер камеры (если используется видеорегистратор), последняя: номер видеопотока (201 означает первый поток второй камеры).

Всего к системе безопасности Ajax можно подключить:

Примеры

Эти примеры стримера и MSE плеера используют Web Call Server 5 в качестве сервера, конвертирующего WebRTC видеопоток для использования в Media Source Extension.

В качестве стримера используем веб-приложение Two Way Streaming, которое отправляет WebRTC видеопоток на сервер.

В качестве плеера, используем тестовый плеер с поддержкой Websockets и MSE.

Код плеера MSE работает через высокоуровневое API.

Создаем div — элемент на HTML-странице

И далее вызываем воспроизведение видеопотока.

Передаем div — элемент параметром display и MSE плеер будет вставлен в этот div-блок.

session.createStream({name:"stream22",display:document.getElementById("myMSE")}).play();

Аналогичным образом работает публикация WebRTC потока с другой страницы.

Потоку назначается уникальное имя stream22, которое будет указано при воспроизведении.

session.createStream({name:"stream22",display:document.getElementById("myWebCam")}).publish();

Полный код стримера и плеера можно найти на github.

— стример — плеер

Возможности приложения Ajax при просмотре видеопотоков

При просмотре видеопотоков в приложении Ajax видео не ухудшается в качестве. Качество видео зависит от камеры и её настроек.

В некоторых камерах в RTSP-ссылке можно указать качество видео.

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

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

Чтобы поставить видео на паузу, нажмите кнопку паузы.

Чтобы сделать фото, нажмите на кнопку, отмеченную на скриншоте. Скриншот сохраняется в память смартфона.

Изображение с камеры также можно масштабировать жестом «щипок».

Подключённые IP-камеры работают независимо от хаба. Если хаб потеряет связь с сервисом Ajax Cloud, а камеры или регистратор продолжат работать — видеопотоки будут доступны для просмотра в приложении Ajax.

В настройках камеры

Ссылка на основную публикацию