Трансляция rtmp видеопотока из live encoder на webrtc

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

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

Тестирование задержек RTMP vs WebRTC

Проведем похожие тесты с RTMP- плеером через Wowza сервер и одновременный тест с WebRTC-плеером через Web Call Server. Слева забираем видеопоток с Wowza в RTMP-подключении. Справа забираем поток по WebRTC. Сверху абсолютное время (нулевая задержка).

Тест — 1

Тест — 2

Тест — 3

Тест — 4

Результаты тестирования можно вывести в уже знакомую таблицу:

  Metric Zero RTMP WebRTC
Test1 Time 37.277 35.288 36.836
Latency 1989 441
Test2 Time 02.623 00.382 02.238
Latency 2241 385
Test3 Time 29.119 27.966 28.796
Latency 1153 323
Test4 Time 50.051 48.702 49.664
Latency   1349 387
Average 1683 384

Таким образом, средняя задержка при воспроизведении RTSP потока в Flash Player по RTMP составила 1683 миллисекунд. Средняя задержка по WebRTC 384 миллисекунды. Т.е. WebRTC оказалась в среднем в 4 раза лучше по задержке.

Способ 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.

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

Шаг 1: Установите программное обеспечение.

Чтобы установить NetCamCenter 3.0 в 64-разрядной версии операционной системы Windows, запустите ncc3_x64.exe или ncc3pro_x64.exe, чтобы начать установку. Чтобы установить NetCamCenter 3.0 в 32-разрядной версии операционной системы Windows, запустите ncc3_x86.exe, чтобы начать установку.

Выберите язык. Нажмите кнопку «Далее.

Нажмите Я согласен.

Нажмите « Установить» или « Обзор», чтобы выбрать папку для NetCamCenter.

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

Как получить поток RTSP с камеры

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

Если поддержка заявлена, то в инструкции будут прописаны настройки для доступа к трансляции. Они представляют собой ссылку для подключения в следующем формате:

Здесь rtsp — указание на протокол подключения, addr — IP-адрес камеры. Через двоеточие указан порт. Последний может отличаться, если в настройках указан отличный от «дефолтного».

Далее следуют user и password — логин пользователя и пароль для подключения (их может и не быть). После них указываются дополнительные параметры, который у разных камер могут отличаться.

Способ 1 — RTMP

RTMP протокол браузеры не поддерживают, но его поддерживает старый добрый Flash Player, который работает неплохо, хоть и не во всех браузерах, и может отобразить видеопоток.

Код плеера в этом случае будет построен на Action Script 3 и выглядеть примерно так:

var nc:NetConnection = nc.connect("rtmp://192.168.88.59/live",obj);
var subscribeStream:NetStream = new NetStream(nc);
subscribeStream.play("rtsp://192.168.88.5/live.sdp");

В этом примере:

rtmp://192.168.88.59/live — это адрес промежуточного сервера, который заберет RTSP видеопоток с камеры и конвертирует его в RTMP
rtsp://192.168.88.5/live.sdp — это RTSP адрес самой камеры.

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

Выглядит это так:

Шаг 5: Рекомендуемые настройки системы.

Хотя NetCamCenter будет пытаться работать непрерывно, ваше оборудование, драйверы и другое программное обеспечение могут переопределять его. Рекомендуется вручную настроить эти параметры.

Прежде чем запускать NetCamCenter, оптимизируйте Windows для запуска NetCamCenter.

  • Отключить спящий режим
  • Проверьте управление питанием вашего сетевого устройства.

Отключить спящий режим

    • Перейдите в панель управления и нажмите « Параметры питания» .
    • Нажмите Изменить настройки плана .
    • На странице « Изменение настроек для плана» выберите « Никогда» для « Перевести компьютер в спящий режим» .

Проверьте управление питанием вашего сетевого устройства

    • Перейдите в панель управления и нажмите « Диспетчер устройств» .
    • Нажмите на Сетевые адаптеры , а затем выберите свой сетевой адаптер. Щелкните правой кнопкой мыши на сетевом адаптере и выберите « Свойства» .

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

Настройка Microsoft Security Essentials. Для настройки Microsoft Security Essentialsвыполните следующие действия. ( Примечание: вы можете отключить сканирование по расписанию, чтобы избежать снижения производительности системы. )

    1. Дважды щелкните Microsoft Security Essentials .
    2. Перейдите на вкладку « Настройки
    3. Нажмите Исключенные файлы и местоположения . Нажмите Добавить.
    4. Выберите папку, в которой установлен NetCamCenter . Нажмите Сохранить изменения.
    1. Нажмите Исключенные типы файлов . Нажмите Добавить.
    2. Введите * .asf .
    3. Нажмите Добавить. Введите * .jpg . Нажмите Сохранить изменения.

Результаты

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

Способ отображения
Применение
Задержка
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 перечисленных направлениях.

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

По синтаксису и операциям протокол 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-

Что нужно выяснить до подключения RTSP камеры?

Поддерживает ли камера RTSP протокол

Как правило, эта информация указана на сайте производителя в характеристиках устройства. Если такая информация отсутствует — воспользуйтесь онлайн-сервисами. Например, http://www.ispyconnect.com/:

  1. Выберите производителя камеры.
  2. Найдите вашу модель устройства. Если устройства нет в списке, оно не поддерживает этот протокол и подключить её к системе безопасности Ajax при помощи RTSP ссылки не получится.

Предоставляет ли ваш интернет-провайдер внешний статический IP-адрес

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

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

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

Real-Time Streaming Protocol (RTSP) в Nimble Streamer

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

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

Контент можно также брать на вход по протоколам RTMP, SRT, NDI, 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 (посмотреть пример настройки сценария)
  • SRT
  • NDI
  • SLDP
  • MPEG2TS
  • Icecast audio
  • Генерация thumbnails-картинок для исходящих потоков.

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

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

  • Переключение на пришедший поток для покрытия таких требований как 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 при этом выглядят наиболее оптимальными.

Ссылки

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 — исходный код мобильного приложения.

Есть ip-камера (embedded устройство с FreeRTOS), которая отдает видео поток (H.264). Просмотр реализован в браузере, с использованием VLC

Вопрос: Как реализовать просмотр видео потока в браузерах (IE, FF, Chrome) без VLC? Если ли open-source решение (на базе Flash, Java или иное)?

Есть некое устройство — мобильный видеорегистратор на базе платформы armhf, работает исключительно через веб-интерфейс. Было неплохое решение по отображению RTSP потока в браузере (Chrome) работавшее на базе расширения VXG Media Player (PNaCl расширение), однако в Chrome 76 оно перестало работать. Как я понял, сейчас для всех NaCl/PNaCl расширений требуется Origin Trial, который Google выдает, и то до декабря 2020, а дальше полный отказ. Ошибка в консоли браузера выглядит так «PNaCl modules can only be used on the open web (non-app/extension) when the PNaCl Origin Trial is enabled». Но есть сложность — все это решение работало на устройстве, которое получает адрес по DHCP, в общем домена нет, адрес постоянно меняется — Origin Trial, как я понимаю, не получишь.

Пошёл в поисках нового решения по трансляции RTSP потока.

Попытка использования ffserver + ffmpeg особо ничего не дала — задержка огромная, довести качество до уровня предыдущего решения не удалось (ранее было FHD разрешение с отличным качеством в браузере).

Следующее решение в теории расписанное везде — использование websocket или WebRTC. И есть готовые решение от Streamdian и Flashphoner. Бесплатные плееры есть, но их websocket-сервера стоят прям немало, да и лицензии на них привязываются к IP/домену. В общем не очень годится. Хотя решение от Streamdian протестировал, качество есть, задержка 5-10 сек, и с небольшими косяками, но возможно можно довести до ума.

Есть бесплатный websocketd (есть даже скомпилированное решение под armhf, которое мне нужно), но как через него прогонять RTSP — — как то непонятно. По факту websocketd проксирует в веб любую программу, использующую stdin/stdout. Для проксирования RTSP нужен какой то проксирующий скрипт.

Конечно, как вариант, остается писать десктопное приложение, но пока не очень хочется.

Что еще не пробовал — это HLS.

Может кто еще другие варианты знает, пока я тестирую HLS.

VLC Media Player — программа для просмотра RTSP видеопотока. Инструкция. Скачать

VLC Media Player обладает широким набором инструментов для работы с медиаконтентом. Он удобен, интуитивно понятен и может заменить сразу несколько программ.

Программа VLC media Player, или как ее обычно называют просто VLC, – это бесплатный кроссплатформенный медиаплеер с широкими возможностями.

Скачать программу можно с сайта разработчика ПО, перейдя по этой ссылке.

Программа работает на следующих OS:

  • Microsoft Windows.
  • Mac OS X.
  • Windows Phone.
  • Linux.
  • iOS.
  • Android.

Примечательной возможностью, которую предоставляет проигрыватель является воспроизведение RTSP-потока. RTSP — это протокол потоковой передачи видео в реальном времени, Real Time Streaming Protocol. В современных тенденциях, в сфере IP видеонаблюдения всё чаще встречается аббревиатура RTSP.

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

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

Real Time Streaming Protocol – это прикладной потоковый протокол, описывающий команды, которые служат, чтобы управлять видеопотоком. Команды могут указать IP-камере либо серверу совершать различные действия, к примеру, начать транслировать поток, либо остановить передачу видеоданных.

В параметрах IP-камер может встречаться различное обозначение потокового варианта передачи информации. RTSP, как было сказано выше, является, по сути набором команд, с помощью которого осуществляется управление потоком. Аббревиатуры UDP и RTP указывают на транспортный механизм, применяемый при передаче видео.

Открытие RTSP-потока в VLC

Чтобы поток с камеры отображался в окне проигрывателя, требуется предварительная настройка ВЛЦ. Выполняем ниже перечисленные пункты инструкции.

    1. Запускаем VLC и заходим в меню «Инструменты», а затем выбираем «Настройки».
    2. Переходим на вкладку «Ввод/кодеки», кликнув по соответствующему значку.
  1. Переводим переключатель «Транспорт потока Live 555» раздела «Сеть» в положение «Использовать RTP поверх RTSP (TCP)» и нажимаем кнопку «Сохранить».
  2. Открываем меню «Медиа» и заходим в пункт «Открыть URL…». В открывшемся окне добавляем ссылку на поток в поле «Введите сетевой адрес». IP-адресацию и другие параметры, из которых состоит адрес можно выяснить, обратившись к документации IP-камеры или видеорегистратора.
  3. Воспроизведение RTSP-потока начнется вслед за нажатием на кнопку «Воспроизвести».

16, Июль, 2019|Программы для видеонаблюдения|

Реализация

Серверы

  • 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

Specifications of an RTSP HTML5 player

The video stream is captured from the RTSP source that delivers audio and video in the supported codecs, and transformed on the server side for subsequent playback in browsers and mobile devices. 

RTSP sources RTSP codecs Playbacktechnologies Playbackplatforms
  • IP cams
  • Media servers
  • Video surveillance
  • Conference servers
  • H.264
  • VP8
  • AAC
  • G.711
  • Speex
  • WebRTC
  • Websocket
  • MSE
  • HLS
  • Flash
  • Chrome
  • Firefox
  • Opera
  • Safari, Mac OS
  • Safari, iOS
  • IE
  • Edge
  • iOS SDK
  • Android SDK

RTSP sources

  • IP cams
  • Media servers
  • Video surveillance
  • Conference servers

RTSP codecs

  • H.264
  • VP8
  • AAC
  • G.711
  • Speex

Playback technologies

  • WebRTC
  • Websocket
  • MSE
  • HLS
  • Flash

Playback platforms

  • Chrome
  • Firefox
  • Opera
  • Safari, Mac OS
  • Safari, iOS
  • IE
  • Edge
  • iOS SDK
  • Android SDK

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

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

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